sabino

Phil & IdealData, thanks for taking the time to offer your comments & assistance. I must admit, however, there for me is still some ambiguity about the specific aspect of whether one needs to have two complete and separate Runtime versions of a particular .fp8 solution. As "IdealData" noted in his response (Post 238352): and As pointed out, Runtime solutions have two components: • the platform specific runtime engine (app & resources) . . . . AND • one or more data files (.USR files) While the Runtime engine is platform specific,. . .the .USR data files are not. In fact, a particular .USR file can be readily opened by FM Pro on either a PC or Mac. So . . . couldn't one construct a Runtime solution folder that contained both the sets (Mac & PC) of Runtime app engine files and just ONE set of .USR data files ? This way, the same Runtime folder could be distributed to all users. An end user would simply click on their platform specific engine (.app or .exe) to startup the solution on their respective machine. They could even take the solution with them back & forth across platforms if they had to change machines. What do others think about this ? sabino .

I would like to check with this group for explicit detailed directions & clarification about binding an FM 8 Adv source file into a runtime solution for cross-platforn use. (I do not wish to use Virtual PC) When the initial binding is completed on platform-1 (either Mac or PC), does one have to take the entire folder of the new runtime solution and copy/transfer it to the OTHER platform-2 and then use an installed copy of FM 8 Adv. on that to re-bind the same runtime ?? Must I take the original source file over to plat-2 also ? ... and if so, do i actually do the second re-binding on the source file or do i perform the second bind on one of the files already in the runtime solution folder ? If i have this correct, doesn't this process create a number of extraneous .DS files visible when viewed on PCs ? Thanks in advance for your time & assistance. sabino

If I may, I would like to suggest another approach; one which I have used successfully for a different purpose but still to bring focus & strong emphasis to certain critical data values. Leave your fields as date-fields, so they can be formatted as such and can still also be used in date-calculations. Rather than TextColor, have the "background" change color based on some calculation (date) result. so if for example, a payment were 31 days late the background would be yellow, if 60 days late it would be red. I set it up this way: -create g_BkgrndClrs a global container with 2 (or more) repetitions. past into each Rep a different color to use. this container will be used as a de facto library resource which you can reference for other fields too. - create Pymt_Bkgrnd an unstored calculation of expression =Case(DatePaid-DateDue>60;GetRepetition(gBgndClrs;1);DatePaid-DateDue>30;GetRepetition(gBgndClrs;2) ;GetRepetition(gBgndClrs;3)) - format DatePaid field in any Date formatting you wish, but . . . choose field to be transparent **no color**. note size of field - place Pymt_Bkgrnd on layout, then position DatePaid field on layout stacked on top of same sized Pymt_Bkgrnd - the field will now change color based on date entered in Payment date-field