ResEd aborts on empty ActionButton
[Fixed]
ResEd 0.61 (and 0.60 too) aborts when you remove an ActionButton's text and click OK. The abort is at offset &0000CF5C in the Toolbox Window module (v1.80).
Although the bug appears to be benign it has some strange effects on starting Toolbox based applications.
Apps that open their main window automatically will have lost all the gadgets implemented by the Window module (eg no ActionButtons but TextArea still present).
Apps that don't open windows on startup will have the gadgets used in their windows shown on the desktop, and if you open a window then all Window based gadgets will be absent.
For some reason opening the gadgets palette in ResEd seems to 'fix' this issue with gadgets.
Draw toolbox can autoscroll
[Fixed]
Make an object in Draw, and drag it over near the right-hand edge of the toolbox, which will start scrolling. Release the object and you can now autoscroll round the toolbox by moving near the edges.
Toolbox method ColourDbox_GetColour aborts when ColourDbox object isn't open
[Fixed]
The method ColourDbox_GetColour aborts when the ColourDbox object isn't open. The aborts seem to come from line 314 in:
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Toolbox/ColourDbox/c/miscop?rev=4.2;content-type=text%2Fx-cvsweb-markup
Contrasting this with line 301 (used when ColourDbox is open) which does work suggests that there is an & operator out of place.
Toolbox method Button_GetFlags can return an incorrect value
[Fixed]
The method Button_GetFlags doesn't return the correct value when the button flags have been toggled with Button_SetFlags.
Button_GetFlags doesn't read the flags using Wimp_GetIconState but returns an internal copy of the button flags. The internal flags however are not calculated correctly in Button_SetFlags at line 247:
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Toolbox/Window/gadgets/c/button?rev=4.2;content-type=text%2Fx-cvsweb-markup
It's doing:
l->flags = (l->flags & ~w.clear_word) | (w.EOR_word & w.clear_word);
Instead of:
l->flags = (l->flags & ~w.clear_word) ^ w.EOR_word;
Possibly because earlier versions of the C compiler didn't support the ^ operator.
The end result is that the internals flags do not match the actual button flags when flag bits are toggled. This may result in, say, the button's selection state not being shown correctly.
ResTest crashes with "Date" object [WorksForMe]
Steps to reproduce:
* Load !ResEd
* Click on iconbar icon ("Untitled1" window opens)
* Menu on Untitled1, select "Prototypes...".
* Drag "Date" from Prototypes to Untitled1.
* Menu on Untitled1 -> File -> Save -> save it somewhere.
Then:
* Load !ResTest
* Drag saved file to ResTest iconbar icon.
"ResTest may have gone wrong [blah blah]"
Describe:
"Internal error: abort on data transfer at &FC409730", postmortem is not so helpful:
9f24 in anonymous function
cee4 in anonymous function
d170 in anonymous function
9518 in anonymous function (function names are GOOD!)
9cd0 in anonymous function
Arg2: 0x00009b84 39812 -> [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe24dcf81]
Arg1: 0x00010138 65848 -> [0x7365523c 0x74736554 0x72694424 0x52212e3e]
fc16cfd8 in shared library function
d464 in anonymous function
ResEd v0.53
ResTest v0.73
RISC OS home-built, v5.21 based upon sources of 2014/01/03.
Side note - in the Date object properties, most of the icons have no effect. If I change "Integer" to be "1" instead of "0", RedTest will now load the file, but trying to create the Date object will fail with "SWI &100340 not known". This number is the class number of the Date object.
There does not appear to be a Date module in the Toolbox collection, nor is such a thing unplugged, nor does such a thing appear to be present in the sources - https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Toolbox/
Nor, having just looked, is there any mention of it in the Toolbox PDF.
Looking within ResEd, it looks like it is handled by !Misc as an "unknown" object; and is apparently defined in !Misc.!Config as @0x100340,Date,obj_date@.
Therefore, should this "Date" object not be present?
Toolbox modules don't fault out of range SWI numbers
[Fixed]
Seems to affect all of them, the 'default' case in the switch/case statement returns NULL (no error) rather than CMHG's magic -1 value.
Ticket search results don't display ticket status
[Fixed]
# ""toolbox"":https://riscosopen.org/tracker/search?q=toolbox
# ""pointer"":https://riscosopen.org/tracker/search?q=pointer
* Obviously not a major issue in cases giving only a handful of results.
* Displaying the part and severity might also be helpful, particularly for someone wanting to kill two birds when about to investigate an unreported issue.
** (An enhanced enhancement could be to build the results into a searchable table "like the full list":https://riscosopen.org/tracker/ (including filters?) but this would mean the details not being shown.)
If the outcome is a WontFix because time could be better used elsewhere, that will make sense - but I thought I'd just note it for consideration.
TextGadgets post-filter's handling of Toolbox_ObjectDeleted is dangerously broken.
[Fixed]
The first time that a Scrollbar, ScrollList or TextArea gadget is created for a client task, the TextGadgets module uses Toolbox_RegisterPostFilter to register SWI TextGadgets_Filter to be called before delivering events of type Toolbox_ObjectDeleted for Toolbox objects of Window class. Unfortunately, the code for handling Toolbox_ObjectDeleted events is horribly broken.
It searches the internal arrays of gadgets of each type for any which have a parent object ID which matches the Window that was just deleted. Upon finding such a TextArea or Scrollbar, it copies all the pointers above downwards, but does so in a very stupid and dangerous way ([n] := [2n], [n + 1] := [2n + 1], [n + 2] := [2n + 2], etc.) In fact, this corrupts the array contents from the orphaned gadget upwards:
// Found one!
int j;
for (j = i; text_area_list[j] != NULL; j++)
{
// Copy down following gadgets
text_area_list[j] = text_area_list[j+i];
}
After having corrupted the contents of the array of pointers, the memory block containing it is expanded to a silly size instead of being shrunk, because the wrong type specifier is used with the 'sizeof' operator:
new_list = realloc(text_area_list,
sizeof(PrivateTextArea) * (remaining + 1));
(The actual type of 'text_area_list' is 'PrivateTextArea **' and not 'PrivateTextArea *'.)
I believe that SWI TextGadgets_Filter is never called for Toolbox_ObjectDeleted events because Toolbox module's post-filter dispatcher is unable to determine the class of an object referenced in a Toolbox event if that object ID is no longer valid (as in this case). Therefore it uses 0 as the class ID, which mismatches the class ID specified in the TextGadgets module's array of event interests.
TextGadgets module uses OS/BBC-compatible error no. 0 (clashes with BASIC).
[Fixed]
Many of the OS error blocks that may be returned by the TextGadgets module use a nominal error number of 0, instead of a proper error number from an allocated chunk.
This is very bad practice because error 0 is one of a block of 256 error numbers allocated for operating system / BBC-compatible errors. According to the BBC BASIC manual, it can have the following meanings:
Corruption of stack
Error control status not found on stack for RESTORE ERROR
HELP has no information on this keyword
Incorrect in-core file description
Invalid LISTO option
Invalid TWINO option
Line too long
Line numbers larger than 65279 would be generated by this renumber
LIST/TWIN found line number reference
Missing incore name
No room
No room to do this renumber
Stopped
An unwelcome consequence is that if SYS "Toolbox_ObjectMiscOp" generates error 0 then BASIC does not call any error handlers set up by the program. Therefore, an application written in BASIC may bomb out and lose all the user's data if it uses Toolbox methods provided by the TextGadgets module.
This is demonstrated by the following BASIC program, which does not print "Handling error, Fish!" as might be expected:
ON ERROR: ON ERROR OFF: PRINT "Handling error ";ERR;", ";REPORT$:END
DIM block% 256
!block% = 0
$(block%+4)= "Fish!"+CHR$0
SYS "OS_GenerateError",block%
Ticket #616 comment by Sprow (202)
[Fixed]
Bug is in Window module https://gitlab.riscosopen.org/RiscOS/Sources/Toolbox/Window/-/merge_requests/2
Ticket #305 comment by Sprow (202)
[Fixed]
Progress update - fixed in my local copy, but blocked by a change to the build system needed to let the Toolbox use the shared makefiles.
Ticket #377 comment by Sprow (202) [WorksForMe]
I mashed the keyboard with the terms "date toolbox module risc os" into google and behold:
http://www.tankstage.co.uk/Software/
I don't get an abort without the module, it just says "SWI &100340 not known". All seems reasonable to me.
Ticket #367 comment by Dick Tanis (1648)
[Fixed]
Changed ticket bug almost back to it's original title. The configure plug-ins are working correctly. Read page 15 of the toolbox manual and found out that Toolbox searches for Message
Ticket #367 comment by Dick Tanis (1648)
[Fixed]
Also the configure plug-ins which use Toolbox for their resources don't use the Messages