Toolbox: Scrolling list breaks action button?

I can’t get action buttons to coexist with a scrolling list. It’s nice and easy to test:

1. Open up ResEd and create a new file.
2. Add a window.
3. Add an action button to the window.
4. Save the file and open it in ResTest.
5. From ResTest’s icon bar menu go to Create/Window, then Show/Window, then click the button and note that it generates an ActionButton_Selected event.

All is well so far. But now add a scrolling list to the mix:

1. In ResEd, add a scrolling list to the window.
2. Save and open in ResTest.
3. Repeat the same steps as above, and notice that the ActionButton_Selected event doesn’t get generated. The window doesn’t close either.

Am I doing something wrong or is this a bug?

I’m running 5.24 and as far as I know am using the bundled Toolbox modules.

It does look to be a ROOL thing, it fails as described here on OS5.25 but works as expected on OS4.39 VRPC.

It seems it only fails when the gadget id of the ActionButton is lower than that of the scrolling list.

If you add a second ActionButton after the scrolling list then that one does generate ActionButton_Selected.

Yes creating the actionbutton after the scrolllist works. Creating before the scrolllist doesn’t work in textgadgets 0.29 (the earliest I could compile) either. So maybe it has never worked. Textareas work ok and the wimp polling code is similar.

How bizarre (gadget IDs). Thanks; I’ll try reshuffling things.

The fault does occur on OS4.02 with Window Object 1.59 but not on OS4.39 with Window Object 2.13.

Changelogs would be useful at this point! I think I do have some somewhere.

I’ve definitely seen ROL’s Toolbox changelogs but naturally I can’t find them now!

but naturally I can’t find them now!

And neither can I!

Found them. Sort of. They used to be on the ROL site, but they disappeared and required the Wayback Machine. They were subsequently removed from that, for reasons.

Fortunately Rick mirrored them in a post here.

PS. Since I just realised that I never actually mentioned it, yes, rearranging the IDs fixed my problem. Thanks :)

Fortunately Rick mirrored them

Fortunately from the Wayback link Rick gave a filename was revealed which I was then able to find on the Foundation 21 CD.

As Colin indicates above the issue is with TextGadgets. The fix is somwhere between 0.19 and 0.95.

[Removed – I was having another problem but 20 seconds after posting realised that I was referencing the wrong window…]

OK, next question:

The StrongHelp manual for the scrolling list states that scrolllist_add_item can take a tab-separated string to create multi-column output. It notes that this feature was added in TextGadgets 0.26.

OS 5.24 includes TextGadgets 0.44 but using tabs doesn’t seem to work. Furthermore the ROOL CVS logs don’t show anything of the sort happening in 0.26. The change log linked above shows 0.26 as being released in 2002, but CVS doesn’t show a single change to TextGadgets in that entire year.

My conclusion is that we’ve ended up with some ROL documentation in ROOL’s Pi image. Does it seem like that’s the case?

My conclusion is that we’ve ended up with some ROL documentation in ROOL’s Pi image. Does it seem like that’s the case?

It does indeed!

Toolbox StrongHelp 1.30 is dated 31-Jan-06.

It notes that this feature was added in TextGadgets 0.26.

ROL’s OS4.29 contained TextGadgets 0.27.

The change log linked above shows 0.26 as being released in 2002, but CVS doesn’t show a single change to TextGadgets in that entire year.

As you noted the change log Rick quoted was from an archive of ROL changes.

It should be noted that the StrongHelp manuals are not fork specific and are not ROL, nor ROOL, documentation.
If the StrongHelp manual doesn’t distinguish between the ROL release Toolbox modules and the ROOL then perhaps it needs a little editing.

ROL’s OS4.29 contained TextGadgets 0.27.

Interesting. Do you have a complete 4.29 you could let me have under the provisions of European Directive 2009/24 ¶15 “to obtain the necessary information to achieve the interoperability of an independently created program with other programs”?

A history:

If the StrongHelp manual doesn’t distinguish between the ROL release Toolbox modules and the ROOL then perhaps it needs a little editing.

Exactly what use is a Toolbox API that does different things on different users’ computers? If there are two different set of functionality, then in effect the functionality is the intersect of those sets, and that’s all. Anything else is implementation detail.

Do you have a complete 4.29

Edit – Was temporarily available.

Please let me know when you have it.

Many thanks for that. I shall add it to my table of randomly changing version numbers and chronologically impossible module dates.

Somebody’s got to do it. ;-)

Exactly what use is a Toolbox API that does different things on different users’ computers? If there are two different set of functionality, then in effect the functionality is the intersect of those sets, and that’s all.

I think of it as the result of a technological mutation of benefit with unfortunate ties to an evolutionary dead end.

I think I agree with you (but it’s pleasingly hard to be certain). My long standing criticism of The Other Lot was extending APIs for some but not all was not extending APIs at all.

I draw a distinction between functionality (and efficiency) and API – it’s acceptable to supply a ConvertPNG module that calls out to a PD command-line utility (for example) – it’s pointless saying ‘here is an API for converting PNGs but if it’s not available, make other arrangements’.

If the programmer makes other arrangements, why bother with the API?

My long standing criticism of The Other Lot

Doesn’t that depend on where you’re standing?

extending APIs for some but not all was not extending APIs at all.

Indeed, I seem to recall that some items from “Really Good Software” had a dependency on an ROL toolbox element that in actual fact didn’t need to be used to give the functionality and that later versions removed the ROL toolbox dependency.
Dependency removed, one less developer using the extended API.

The table below shows Toolbox version numbers taken over the years from machines here.

It’s ever so interesting.

Toolbox modules        Sel3   Sel4   Iyonix ROOL   ROL
                4.04   4.39   6.20   5.03   5.24   32bit
                ROM    ROM    ROM    ROM    ROM    Soft
ColourDbox      0.18   0.28   0.39   0.19   0.22   0.23
ColourMenu      0.19   0.27   0.40   0.21   0.22   0.24
DCS_Quit        1.08   1.19   1.25   1.11   1.14   1.17
FileInfo        0.17   0.24   0.33   0.18   0.20   0.22
FontDbox        0.17   0.24   0.39   0.18   0.19   0.22
FontMenu        0.21   0.28   0.39   0.24   0.25   0.27
IconBar         1.18   1.23   1.30   1.20   1.23   1.22
Menu            0.35   0.44   0.60   0.36   0.40   0.40
PrintDbox       0.14   0.22   0.39   0.16   0.18   0.20
ProgInfo        0.15   0.22   0.31   0.17   0.18   0.20
SaveAs          0.16   0.24   0.41   0.17   0.20   0.22
Scale           0.14   0.21   0.32   0.15   0.16   0.19
TextGadget      0.19   0.85   1.05   0.26   0.44   0.49
ToolAction      0.17   0.27   0.31   0.28   0.38   0.25
Toolbox         1.45   1.78   1.94   1.52   1.58   1.71
Window          1.59   1.95   2.22   1.69   1.79   1.81

The last column is ROL’s 32bit set for use with the Iyonix. As I recall it was the Select OS4.37 set.

ROOL does not support the use of this.

API reunification and version number monotonicity need to be a priority IMO.

API reunification and version number monotonicity need to be a priority IMO.

Can’t find fault with that, except for a slight shortage¹ of programming talent.

¹ Personally, a lot more than “slight”

API reunification and version number monotonicity need to be a priority IMO.

We now have a bounty.

We now have a bounty.

For Toolbox and more…