>>Upon trying to set the lists in my window to display in bold (they
>>originally drew as plain text), I found the following:

<snip>

>Click the lists in PG with the selection tool (the arrow) to change the
>font, or size, or style, or color.

Thanks for that tip, Chris. :)

>>In addition, another bug surfaced, but needs more explanation. I recently

<snip>

>Kaleidoscope does some improper things with the window fonts. I would not
>depend on it to handle changes in PG. The font selection in Text & Textures
>is for new text going into edit fields. The font for lists is set by
>clicking the list with the selection tool. (See above)

Hmmm ... ok, I understand where you're coming from there, but I guess I
didn't make it clearer the first time. No matter tho, furthur
experimentation showed that the bug was there whether Kaleidoscope was
enabled or disabled. It seems that if I select the Text and Textures item
and change the style more than once without saving the PG resource file, PG
crashes.

If I save after making a style change to the window, then I can change the
style again with no problem. It's only when I don't save before selecting
the Text and Textures item and attempting to change the style again that PG
freezes, my system freezes and I have to cmd-ctrl-pwr.

>>Please don't tell me I have to recreate the window from scratch because
>>it's somehow gotten corrupted! :(( I don't want to! <pleading and banging
>>fist on desk> hehehe
>
>You need to work on debugging the code instead of pointing a finger at
>Kaleidoscope or at PG or thinking that your file is permenantly corrupted.
>Try running with the debugger on. Before the window is opened, make sure
>that your debugger is running and showing every line as it executes. When
>the program freezes, you'll see what line caused the problem.

hehe sorry ... that was supposed to be a joke. Plus, the problem isn't in
the code produced by PG, it's in the PG app. The code produced runs fine
and with no problems (in FB anyway, I'm nowhere near ready to build and run
as stand-alone yet).

>>
>>While I'm on the subject of lists and bold vs plain text, is there a way I
>>can make the list title bold and leave the list contents plain text?
>>
>
>Make a list with no title, then put a text box over the area where the
>title belongs.

Thanks for this tip too! It solves my bold problem totally :)

>>Now to a question that I believe was covered before on this list, tho I
>>don't recall an answer and haven't found an answer in the archives I have.

<snip>

>There is no simple solution.I could go into all the reasons that this
>happens, but it would not help you. May I suggest that you create the
>entire window as a pict and drop all of the background color and pattern
>stuff. Your background picture can have white cutouts for edit fields.

Hmmm ... sounds reasonable I guess ;) I have thought of the background pict
idea, but just figured it would be easier the other way, heh.

>>OK, that's it for that part of my problems. Now on to the real problem. As

<snip>

>To get a picture, you would use...
>
>pictHndl& = FN pGget1NamedRes(_"PICT",theName$,gResRef)

On this one, I sorta figured it was something like this. In the DocViewer
version of More Toolbox, I was reading that this call only finds and gets
one resource (meaning the actual toolbox call made within your function). I
read about the other call as well, but I guess I'm missing something
because I don't understand the diff between them (and because you only
wrote one function concerning them heh).

>Draw the picture immediately after you get it as the handle is normally
>purgeable and it may be purged if the next call is not a PICTURE or CALL
>DRAWPICTURE statement. Do not dispose of the handle. Do not call release
>resource.

Thanks for this as well. I think I remember reading something about this
before, but it's nice to have a memory refresher. :)

>>Also, I need to be able to update the resources according to the name of

<snip>

>Since everything in resourcedom works from IDs, I would suggest that you
>rethink this requirement and work with integer IDs instead of names. What
>you are asking is not at all impossible, but you are adding a great deal of
>complexity.

If the program I'm writing was intended to work with only files it created
for it's own use, I would agree with you. However, this is a case where it
is a special circumstance and the file is dealt with by the program that
uses it on a named-resource level because it has to. In order to ensure
that my "editor" doesn't create more problems than it solves, I think I
have to follow the same conventions as the parent program.

>>Additionally, does anyone have a PG function for opening the resource fork
>>of a file? (PG doesn't seem to have a function for that and I'm not sure
>>how to write it.)
>
>rRef = FN OPENRFPERM("The File Name",theVolRef,_fsRdWrPerm)
>
>LONG IF rRef > 0
>  REM do stuff here
>  CALL CLOSERESFILE(rRef)
>END IF

Thanks for the sample. Now I can go to town. :) heh

Wayne

DALnet: Shimmerling
UnderNet, ChatNet, EscapeNet: Randii