[futurebasic] Re: [FB] Trouble using DataBrowser For Dummies with FBtoC [re-post]

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

From: Alain Pastor <apastor@...>
Date: Thu, 10 Jan 2008 18:01:14 +0100
Sorry, if the following contribution comes twice (my first post seems to 
be stuck in twilight zone):

Robert Purves a crit :
> Joe Lertola wrote:
>> FBtoC: translating project TopoToImage3.proj to TopoToImage3.c
>>  Unknown function in line 2160 of DataBrowser For Dummies.Incl: 
>> FBGetWndPointer
>>  2160:  If myColumns.hiddenWnd(0) Then wRef = Fn FBGetWndPointer( 
>> myColumns.hiddenWnd(0) )
>> Fn FBGetWndPointer is defined in Rntm Appearance.incl. Is this a 
>> function that is not supported in FBtoC? If so is there an alternative 
>> function?
> FBGetWndPointer is an undocumented function, in the FB runtime only. The 
> official and supported way to get a WindowRef from an FB wndNum is 'get 
> window'. 
> But why are you struggling with DBFD? Alain wrote it to simplify Apple's 
> complicated DataBrowser API, by providing easy-to-use 'wrapper' function 
> calls and automatic data management. It is unfortunately incompatible 
> with FBtoC. 
> The modern replacement is Bernie's DBData. Look in FBtoC's 
> Examples/DBData (10.4) for a stunning demo. It's already compatible with 
> FBtoC, as this log shows:
> FBtoC: translating project DBData Demo.bas to DBData_Demo.c
> FBtoC: translation time:   0.39 s
> FBtoC: copying files
> FBtoC: copy time:          0.06 s
> FBtoC: using precompiled header
> FBtoC: compiling DBData_Demo.c to DBData Demo.app
> FBtoC: using precompiled runtime
> FBtoC: compiling user code
> FBToC: compile+link time:  0.52 s
> FBtoC: total time:         0.99 s
> FBtoC: launching DBData Demo.app
> FBtoC: done 

Furthermore, let me add that I believe that updating DBFD for FBtoC 
compliance is not doable as is, considering the foundations upon which 
the library has been built. This was a topic of a previous contribution 
a month ago. In short, to make it work natively on Intel Macs its modus 
operandi needs serious rethinking. If anyone is ready to lift that 
gauntlet, I'm willing to help as much as I can, as time permits, but I'm 
not going to undertake that job myself.

This is too bad, because QuiXample uses the DBFD library, therefore that 
convenient tool won't have a universal version anytime soon, unless 
someone is interested in doing the required job, in which case I will 
gladly provide the current source code. Here again, I can possibly help.

Updating QuiXample is quite different from updating the DBFD library, 
because the latter would be more demanding whereas the former should 
boil down to replacing calls to functions in the library with regular FB 
functions (most of the necessary code can be found in the DBFD library 

Note also that as my latest tests show, QuiXample is somewhat unstable 
under Leopard (on dual G5). In addition, I guess Apple engineers have 
changed once again the organization of their documentation files in the 
Developer folder, because some features like searching Apple docs or C 
headers are deactivated right now. Other than that, scanning FB files 
seems to work OK and still lightning fast on my new Dual G5. However, I 
don't know how it fares on Intel Macs under Rosetta.