Forums Bug Reports Cascade/Tile icons unhiding

If using the Alt+E window to connect to a network, the htile vtile cascade icons all un-hide and un-disable themselves.

Same thing happens if I simply click to open 'Options' and then immediately click 'OK'.

I tested as far back as v7.42 and found the current behavior there, but did not find it in v6.35

https://forums.mirc.com/ubbthreads.php/topics/208758/re-toolbar-help#Post208758

The alias in this link from the v6.35 era no longer works completely since '/buttons off' is reversed each time someone uses 'OK' or 'Connect' to exit the options dialog.

--

The next command hides+disables the tile and cascade icons then verifies that they are disabled and Forum users can undo this with /toolbar -r

//toolbar -hb htile | toolbar -hb vtile | toolbar -hb cascade | echo -a $toolbar(htile).enabled $toolbar(vtile).enabled $toolbar(cascade).enabled

--

If I use the lightning-bolt connect icon to disconnect and reconnect the same server, the icons stay hidden and disabled. Same behavior from using /file in the menubar to connect or reconnect.

But if I use the Alt+E hotkey to use the serverlist dialog to reconnect to that server or to open a new server window, these 3 icons immediately are visible in their enabled state.

Clicking the connect button in the Alt+E window also includes an implied clicking 'OK' to confirm other changes elsewhere in the options tree, but there aren't any changes related to the toolbar or anything else being changed or saved.

I can't find anything in OPTIONS related to cascading, and the only things related to the toolbar is for small/large icons or multiline, but I wouldn't expect the act of opening options and clicking OK without doing anything inside should change anything. As a test, I hid all icons:

//var %i 1 | while ($toolbar(%i)) { toolbar -h %i | inc %i }

... and confirmed that these 3 tile/cascade icons and the lightning bolt 'connect' icon are the only ones who un-hide themselves from exiting Options by clicking OK.

I also used /toolbar -fs to save the hidden icons to toolbar.ini so I could confirm that OK'ing out of the options was not auto-loading from toolbar.ini because /toolbar -fl would hide the 3 icons again.


Edit: correction:

The alias does work because it -d deletes these icons instead of hiding them, and clicking OK to exit Options doesn't resurrect the buttons from the dead.

Right, that's a tricky one to solve. There are several features that automatically show/hide these icons depending on context, so another context exception would need to be added for /toolbar -h. I have added this to my to-do list.

For when you look at /toolbar -h, there's also another edge case for /toolbar, having to do when combining a lot of switches together. For the most part it lets you do that, but there's an exception when trying to use either -i or -m at the same time as any of -ebhw.

The next example adapts the /help example to -i insert the Cow button instead of -a appending it, and it works correctly to insert the new button at position 18:

//toolbar -r | toolbar -iz1 18 Cow "Moo moo!" 32x32.ico "/echo I am cow, hear my moo" @cow

however changing the switch to '-ib' returns an error due to thinking that "Moo moo!" is an invalid filename. If I change the tooltip to "32x32.ico" to match the filename containing a valid icon, then /toolbar is apparently satisfied that the tooltip is a valid 'filename', but then returns 'invalid parameter' for some other reason.

Same thing happens for the -m move switch, where this next command moves to position 34 the 'colors' button

//toolbar -r | toolbar -m 34 colors

However including the -w switch to ensure it's visible makes it do-nothing

//toolbar -r | toolbar -mw 34 colors

That's because, as you've discovered, these switches cannot be combined. It's fairly common in most commands/identifiers to have switches that are mutually exclusive. If you use mutually exclusive switches, mIRC will just use one of the them. Which one it uses depends on how the command was implemented, what I thought made the most sense at the time, and so on. Some commands/identifiers will report errors but most will not. This is especially the case with commands that support a large number of switches like /toolbar.

I have been looking into your original bug report about /toolbar -h and have decided to leave this behaviour in place. These are core GUI buttons. If a script does not want them, it should delete them. As long as they are present, they will be updated by GUI features that use them. This actually applies to several other core GUI buttons as well, which need to be updated/shown/hidden according to how certain features work. In this case, there are at least five GUI-related features that have input into how the tile/cascade/etc. buttons are displayed.