I'm working to a theme editor since a couple of years but with long pauses, however now I'm at a good stage I can display more or less properly a bitmapped theme and modify the bitmaps files trough a small dedicated painter. The problem is that some themes are designed to use more the gui prefs data rather than the bitmaps, then on my theme viewer are really ugly. To simulate some of the window behaviour I need to take out some info from gui.pref (and later from palette.prefs etc). A typical case I got is that the titlebar can be selected and stored also in the gui.prefs rather than a file in the bitmap structure. I've seen that the file path (if it is a file, because can be a gradient as well) is always on the position 70 of the gui prefs file. This could be because the file has a fixed structure, or may be it is a chance?
Sounds interesting. I see why you want the info. Hopefully TBoeckel's suggestion about the include file can help.
Quote:
A typical case I got is that the titlebar can be selected and stored also in the gui.prefs rather than a file in the bitmap structure. I've seen that the file path (if it is a file, because can be a gradient as well) is always on the position 70 of the gui prefs file. This could be because the file has a fixed structure, or may be it is a chance?
Life has taught me some valuable lessons about relying on guesswork like this. Go through the official include file instead.
And if the file is an IFF file, you can even less rely on any fixed offsets (except maybe the first few ones). It does need to be parsed the official way, because nothing in principle prevents some chunks from growing or moving within an IFF file.
Thanks for advising, I will dig into this weekend. Unfortunately this project goes slow because I can work on it just during weekends, and obviously not all! Atm is not ready enough for a first release. Hope in a couple of month.
So seems that the structure is fixed. That's good.
*Don't* access that file directly. *Do* use IIntition->GetGUIAttrs() and IIntuitio->SetGUIAttrs(). It's always better to use an API where there is one, as this allows such files to develope in future, without being limited by existing apps peeking them.
That may not be possible from Hollywood, but I'm not sure that Hollywood is agood choice of language for what you trying to do (If I understand correctly) If you want to simulate the effect of changeing theme attributes on a aset of gadgets the best way would be to use the gadgets themselves, as then they will respond exactly as they will in real life (because they are the real thing). If you confident enough to attempt a GUI editor in hollwood I recon you could handle doing it in C too.