Unable to Modify Tooltype with dos_SetToolString{}

[Daedalus]

Hi guys,
It appears that the dos_SetToolString{} function does not set a tooltype if the tooltype already exists. To test, I created a file in RAM: called "Test" with an icon and ran the following code:

Code:

optimize 4

XINCLUDE "dos.include.bb2"

NPrint dos_SetToolString{"TEST","TestString","RAM:Test.info"}

It added the tooltype as expected and gave a successful result (-1).

However, when I change the tooltype and re-run the code, the tooltype is not updated to "TestString". The function still returns success (-1) so I cannot tell that it has failed. Any ideas what might be going on?

Thanks!

[tomsmart1]

Hi Daedalus,

this was not a Bug it a feature ;-)

The hole problem is that creating a new tooltype is a special case where the icon data was updated an saved to disk. By only a change of the Value (or string) it is only updated in Memory and not saved to disk.

That your example work right it is only needed do added the function call "dos_CloseToolTypes{}" add the end of all tooltype changes!

Code:

optimize 4

    XINCLUDE "dos.include.bb2"

    NPrint dos_SetToolString{"TEST","TestString","RAM:Test.info"}
    
    NPrint dos_CloseToolTypes{}

The tooltype changes functions are programed in the mind of doing many Tooltypes changes an the same time and icon like PEd did if you save the prefs. So the functions changes/updates the tooltypes in mem and a the end the Icon is saved back to disk, this saves a lot of time.

But i find a way to get it easy and fast, so with the new version of dos.include.ab3 at Revision 552 the Tooltypes are saved directly after a change if the filename is a parameter of all funtions call of dos_SetTool...{} as in your example a extra call of dos_CloseToolType is not needed. If the filename is not given the functions act as before and a call of dos_FlushToolTypes or dos_CloseToolTypes is need to save it to disk. Also i fixed dos_SetToolState{} so it works now correct befor it used the wrong Pointer to update the Tooltype

[Der Wanderer]

@tomsmart1: Don't change the behavior if the icon file is set or the tooltype is newly created. This slows things unnecessarily down and can be very confusing.
dos_CloseToolTypes is called on auto exit, so you can't miss it unless your program crashes.
Calling dos_CloseToolTypes is absolutely optional and only required if you explicitly want to save it. Otherwise, keeping everything until you close the program is fine.

If Deadalus does not see the update reflected in the icon, then:
1. have you successfully ended the test program?
2. have you closed and re-opened the icon info?

If yes, then this is a bug. But I would be surprised, since I use this functionality almost in all my programs without probs.

[Daedalus]

Thanks for the replies! I will have to check when I go home, but my main use case was when the program was still running and without executing the dos_CloseToolTypes{} call, so that would explain why I didn't see the updates - I reopened the icon info but didn't exit the program.

My test program had the same behaviour but I think that may have had the problem because it did not have an End statement (yeah, I know that's bad but it was just a test). It sounds like that would be caused by Der Wanderer's suggestion of not closing the program properly.

I don't think it needs the functionality changed really if dos_CloseToolTypes{} works, maybe it just needs a note in the documentation to explain how it works. Being able to change lots of tooltypes in one go and save it at the end would have advantages on slower systems, floppy disks etc...

I'll try it tonight and see how I get on and let you know. Thanks for your help!

[tomsmart1]

@Der Wanderer
Sorry, i changed the behavior with Revision 552 of the SVN but only for the case that you use the optional Parameter Filename then the icon is directly saved, i find this more intuitive. I only checked PED an it has no effect becaus it use dos_OpenToolTypes{..} and then all dos_setTool...{} functions without the filename as parameter, but today i checked AIDE and see that you use there the optional Filename Parameter.

So what should i do change it back, or change AIDE to use dos_OpenToolType{filename} in front of the dos_SetTool...{} calls?


For the functionality of autoexit it is needed to end the Program with the Token End. If i added it to Deadalus example then the icon is saved and it works in both case for new and change of the Tooltype.

[Der Wanderer]

The "End" Statement is always required, otherwise the program is broken. It frees the resources allocated by BlitzLibs and Includes.

Please change the tooltypes with explicit icon behavior back to caching it until the Tooltypes get flushed. There is no need to save it directly.

[Daedalus]

Yeah, I know. I normally always use it, just left that off since it was just a small test and never meant to run without the debugger.

Thanks for the help, I've tried using the dos_CloseToolTypes{} call and it now works fine. Also, good to know a little bit more about how these things work!

[tomsmart1]

I revert back the dos.include behavior of dos_SetToolString{} and dos_SetToolState{} with Revision 553 so it not save directly if you use the a Filename as Parameter.

[Der Wanderer]

Thanks