Forums Feature Suggestions Expansion of dialog 'Scroll' control events

I came across the dialog control object of Scroll, and when looking at it's events noticed it is exactly what I would like to see in other dialog controls, the ones that use styles of vsbar & hsbar (and their 'a' [auto visibilty] versions), namely Edit, List and Combo.

Further to that I would like to see scroll controls allow input to the scroll bar rather than just output.

Initially I could not see any use for the scroll bar control snce it could not be bound to any other control, until finding scripts using it to control winamp volume, usually with $did(blah,blah).sel to get the slider's position out asnd feeding it to an edit box.

If it was possible to use the reverse then you could type the vol setting into an edit box and use did to set the control to a corresponding loction on the control bar.

As well as being a logical progression of that control, and it's extension to other scroll bars, it would help me with an other issue, namely linking the scroll positions of 3 side by side tables to keep them in sync - scroll one and the others follow. I have mentioned this in a scripts and pop-ups forum post .

If you have more than 2 issues here, it wasn't clear what you were saying in the 1st paragraph.

As for setting the the position of the scroll bar, it looks like the docs weren't updated to mention scroll for the -c switch, but you can move the square to the desired position like:

/did -c Dname ID Number
... where number is a value within whatever range you defined

As for moving the visible area of a dialog list control, the only way I'm aware of is similar to the kludge needed to do the same thing in a @listbox using /sline.

You can use /did -c Dname ListID LineNum to shift the view of a List. If N is a line above the display, it shifts the display to place line N at the top. If N is a line below the display, it shifts the display enough to show line N 'sorta' at the bottom. Depending on the dimensions of the list control, there can be a partly-visible row at the bottom of the listbox, so if N is that partly-seen row, the display shifts just enough to make it be fully visible. If N is a line that's already in the display, the view doesn't shift.

Since this method selects a row, you would need to uncheck the line with -u like:

//did -c DName ID 1 | did -u DName ID 1

But you now have a problem in that any currently selected line is no longer selected, and you can't reselect it without potentially moving the display back to the other line. Unless N was already the one selected, in which case you wouldn't uncheck it after using it to shift the display.

So now your .sel property needs to reside in a variable or hashtable, and you can't re-select the original selected line until it shifts into view, but you have no way to know when someone uses the listbox's scroll bar to make it visible. So if the user sees their selection is no longer selected, so they click on it - should you treat that as if it's an unselection or a re-selection, etc.

And it gets even messier if you're using extsel options and the user has selected several lines. And even more messier with multsel, where you could have multiple .sel and .csel to track.

Note: I'm also testing a little bit with scrolling to the bottom then doing:

//did -c DName ID 1 | did -u DName ID 1

... as this seems to avoid a lot of the problems dealing with already selected/checked list rows, but it doesn't always jump to the selected row when other lines are already checked.

Yes I was exprssing an opinion on 2 issues

1) It would be nice if the events available for use in the Dialog Scroll control could be applied to other dialog controls that have scroll bars within them.

2) According to all documentation I have ssen the scroll control $did can be used to extract values from the scroll bar, but there were not any documented to do the reverse, did($name, %scroll_bar_lnumber). In other word to apply a movement of the slider within the scroll bar without touching it (click move)

Regarding the -c switch, no mention on WikiChip and cant see it in mIRC Help file.

I also groaned when I saw it mentioned. -c is used in check box controls to set the box as ticked (-u to untick it), getting the state of the tick box you query the .cstate property. Looks logical so far, untill you get to the list obect with style check, where -c isn't used to tick the box, instead it's -s (-l to untick it) but at least it's still the .cstate property to query.

sigh, for consistensy