Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Possible issue with dos_SetToolSwitch{}?
#1
Hi guys, it's been a while since I've been doing some programming, but I'm getting back into it again now. Anyway, on a recent project I seem to have come across what might be a bug in the dos_SetToolSwitch{} function. the dos_SetToolString{} and all the other tooltype functions appear to work ok, but when I try to disable a tooltype by setting dos_SetToolSwitch{} to false my OS4 machine locks up hard. No Grim Reaper, and the debugger doesn't catch the problem.

Stepping through the code doesn't let be catch the problem either as the debugger doesn't step into the dos.include.bb2 file, and so I can't see exactly which command fails. I thought the debugger normally does that? This is with AmiBlitz 3.5 by the way...

P.S. The new site looks well! Will there be an English version for the front page? Perhaps I could help with the translation if you need it?
Zitieren
#2
If you cannot debug the include, there is an "RunErrsOff" around it. Maybe you want to use dos_SetToolBool{} as a workaround?

Switch is a tooltype that just is, like

in "on" state:
DEBUG

or "off":
(DEBUG)

A boolean would do
DEBUG=True
or
DEBUG=False
Zitieren
#3
Der Wanderer schrieb:If you cannot debug the include, there is an "RunErrsOff" around it.
Yes, I couldn't find any in the dos.include, but there must be one in one of the includes used by dos.include itself. Anyway, I added RunErrsOn after the XInclude lines at the start of the dos.include file and I can now step into it with the debugger... Here's where it gets strange:

When the debugger is enabled, the code doesn't crash, no warnings or anything, and the debugger runs through the include without problem. However, the tooltype isn't set to false, instead an extra copy of the tooltype is added below the original (and is also enabled). My exact command is:

dos_SetToolSwitch{"KEEPEXCESS",False,"WorkTonguerogramming/AmiBlitz3/Projects/Atoms-X/Atoms-X"}

and all that happens is that my icon's tooltypes now have:

KEEPEXCESS
KEEPEXCESS

and more, depending on how many times I run it. Creating an executable with this exact code (but the debugger turned off) still crashes immediately at the call to dos_SetToolSwitch{}.

Zitat:Maybe you want to use dos_SetToolBool{} as a workaround?

Switch is a tooltype that just is, like

in "on" state:
DEBUG

or "off":
(DEBUG)

A boolean would do
DEBUG=True
or
DEBUG=False
Yes, I had already done something like this as a workaround (using dos_SetToolString{} instead), just thought it's something that might need to be looked at anyway.
Zitieren
#4
I will have a look into this, but I can darkly remember that we had this issue before, and I couldn't figure out why. It seemed to work fine on OS3.x. Means, if I don't find anything, we must flag this function with "OS3.x only" or you need to find out what's wrong.
Zitieren
#5
Well, I can confirm that it works on OS3.9, though the first time it is run, a few bytes of garbage are put in as a tooltype instead. After that, it works as expected. Perhaps some uninitialised variable or bad pointer or something? Seems like a very tricky issue, but the workaround is simple so it's ok.

Thanks for your help!
Zitieren
#6
It was a bug. Thanks for pointing this out. I updated the svn.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste