FB II Compiler







Disk I/O














Made with FB


Use the new System 8 WDEFs

has anybody managed to use the new system 8 WDEFs for floating windows in an FB app yet? Is so, please show me the trick.

wading through the gunge of the toolbox, here are the latest results:

if you use the FB runtime with FB windows, you cannot get access to OS8 WDEFs, in my case the ProcID of 1070, it seems that FB does a MOD on numbers and gives you multiples of 16...

if you use the FB rsrc2Wnd routine in the sample files, you cannot get the WDEF either - same result.

if you create your own window with NEWCWINDOW, you can use this WDEF, but then the window is 'deatched' from the FB runtime, so you can't use FB objects like buttons and fields in it, you have to grow your own in the Toolbox.

This vindicates what Mel said - ie. in DAs and the miniruntime where growing your own is normal behavior, it is possible - but means that you can't have the new WDEFs in a vanilla FB app, much less a PG app.

Question to STAZ: would it be possible to patch the FB runtime to avoid what looks lie the 'MOD' effect on window types? this would be then an easy way of getting any sort of WDEF in FB...


I too, have been looking at this problem. I have come to the conclution that the reason for this is that the FB Window statement uses the high byte of its type parameter for attributes (eg whether it has a closebox or not). The only possible fix I can think of is to make a FN that emulates FB's Window statement, but allows a full word for the ProcID.
You should know I haven't actually tried this but it should work in theory.

There a three things (that I know of) that need to be done in order to do this.

1)Figure the RefCon that FB would use

bits explanation (From FB Help)
---- ------------------------------
00 - 07....window class
08 - 15....window modal flag (0 = not modal)
16 - 23....window # 0 to # 63
24 - 31....window type -1 (0, 8 are resizable windows)

2)Build the window using NewWindow

3)Add the window to the WndBlk record

offset contains explanation (From FB Help)
--- ------- -----------------------------------
00......Long.......window pointer
04......Long.......pointer to ZTEHandle list (0 = no ZTEHandles)
08......Long.......EDIT FIELD handle currently active (0 = not active)
12......Long.......window clip region (-1 if AUTOCLIP = 0 )

Each program window in the WNDBLK occupies 16 bytes. WINDOW #0 is not a valid window number and is reserved for the compiler itself. To access a particular window record in WNDBLK, use the following formula:

WndRecPtr& = WNDBLK + (Window Number * 16)
(End From FB Help)
You have two options of what to do when the record you want to add you window to is already occupied-- The safest --Just give up or More Risky--Delete the window operating in that space and the insert your own.

Good Luck (I hope this helped),


PS) I recently made a similar FN to emulate FB's Button statement for use with the more exotic of 8.5's new controls. If your interested let me know.

I managed to get some System 8 WDEFs functionning in FB, but it ain't nice.
If you can't live without 'em, then do the following, however, read the note at the end, explaining why it ain't nice...

1/ open your System file with resEdit
2/ open the WDEF resources and copy them into a new file
3/ close the System file - do not save!
4/ inside the copies of the the WDEF resources grab the one that you want and copy it into your project resource file (I wanted ID 66)
5/ inside the project resource file, get the info on this resource and change the ID to 8, unclick the System heap check.
6/ In your program code, program as it you are using the WDEF for floating palettes that is with FBII, defining your windows as _WDEFbaseID (I used +5, to get the grow box).
7/ Most important DO NOT use _includeWDEF in your compile statements (If you do, the FBII WDEF will replace your system WDEF).
8/ Run your code.

This will also work if you use the Infinity WDEF in place of the System one.

Why this ain't hot.
As the code is now in your application resource:
1/ your are duplicating propriety code unnecessarily, and I'm also not sure about the legality
2/ any system wide changes - ie. themes, kaleidoscope, tinges – will not apply to your WDEF
3/ if Apple revises this WDEF in subsequent versions, your code can't take advantage of this revision

You may prefer, because of these remarks, to use the Infinity WDEF by Troy Gaul, that is available on various programmers CD-ROMs, that's where i found it (or someone might provide a URL). It comes with a tool called WDEF tester, that I used in order to find out the WDEF I wanted, and the var code, and is generally a great tool in its own right.


What _I'd_ do, given the WDEF "must" be a given ID... after checking to make sure Appearance Manager is active, etc., in my initialization routine, I'd check to verify that there was a WDEF 66 in my resource chain. (In the System file, one would assume.)

Given all the pieces, I'd then create a "temp file" in the "temporary items" folder that contained only a resource fork, and I'd copy WDEF 66 to it as WDEF 8. Then I'd put that temp file on my resource chain and go from there; deleting the file on exit. That would take care of any concerns about distributing Apple code (it's already on the Mac where we're running), and would pick up any revisions Apple makes. I'm not sure about how themes would work on it.

"Think different!" :-)