[futurebasic] Re: [FB] The file name returns zero part 2

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : January 2011 : Group Archive : Group : All Groups

From: Brian S <fblistserve@...>
Date: Tue, 18 Jan 2011 10:58:24 -0700
On Jan 18, 2011, at 7:42 AM, Yoshiyuki Hasegawa wrote:
> fn NavDialog( _kNavDialogPutFile + _kNavDialogSheet, "Save This File As...", "untitled.abcd", @fn MyPutFileHandler, 0 )
> It is a point that "Untitled.abcd" in the example above cannot be made a character by two bytes.
> Can this be solved?

Both of those input strings to NavDialog are currently pascal strings as you point out. Within NavDialog() ( in FilesDollarFunction.c in the build_goodies folder of the runtime ) it has to change those two pascal strings to CFStrings before a Navigation Services call ( such as NavCreateGetFileDialog() or NavCreatePutFileDialog() ) can be made. Thus the limitation of pascal input strings is a limitation of the runtime NavDialog() and not Navigation Services which uses CFStrings. Most input strings to FB runtime functions ( such as NavDialog ) were designed to keep the pascal strings familiar to most FBers. 

One potential solution is to make changes to NavDialog() to use CFStrings input. The changes are simple to load options.message and options.saveFileName with the appropriate input CFString instead of the current conversion of the pascal string to CFString. Obviously, that change would have to be in a copy of NavDialog() ( and renamed to avoid a conflict with the runtime NavDialog() ) because changing the current NavDialog() would break code that uses it with pascal strings. Maybe call it NavDialogCF() and put it in the runtime. There is more that could be done in this process to clean up the code and eliminate redundancies without having essentially two copies of NavDialog().


> The necessity for operating CFString will come out in the future.
If you mean will the runtime ( not just NavDialog() but all the runtime ) be changed to use CFStrings, I don’t know. It is not a small task and maintaining compatibility with old code is a consideration. It is doable however.


> If they are limits of Carbon, I will give it up, too.


Not sure what “they” are. Carbon has no limits with CFStrings and CFStrings have been available for many years. Carbon’s current limitation is you can’t write a 64-bit GUI application because Apple made the decision years ago to not migrate HI toolbox to 64-bit. That limitation does not currently present any real issues.

BTW: giving up on Carbon is currently synonymous within giving up on FB5

Brian S.