Forums Feature Suggestions Changes to the sclick event for dialogs

I'd like to see some much needed changes to the dialog event handlers.

The changes being: allowing SCLICK events to be triggered on all objects within a dialog, and not limited to single click in list/combo box, or check/uncheck of radio/check buttons, or click of a button. The same goes for dclick.


I would also like to suggest the addition of a mouseover, mousein and mouseout event trigger/s. This would trigger when the user puts the mouse over any object within the dialog. This would allow dialogs to generate real feedback based on the mouse position. For example, one could create a blank text object that when a mouse passed over a certain object in the dialog, would display text akin to a rollover.

This, in my opinion, is much needed.

im not so sure about _all_ controls in a dialog. some events really have no place for some controls. for example what would a dclick do for a radio since an sclick will activate it a dclick cant activate it twice. some controls like text's and box's really have no need for sclick or dclick. also edit controls should have a select event when hilighting text but i dont see how an sclick or dclick would help with those either.

as for the additional mouse events i agree they would be greatly welcomed and it is easy to implement.

(note windows does allow for sclick etc. for statics (text in mirc) so its not that it isnt possible just not very useful)

(note 2 actually i take that back i just thought of a usage)

(note 3 i might get it this time. actually i think instead of focusing on events for controls we already have perhaps adding a few controls we dont may be even better)

I agree with your comment regarding dclick for check/radio/text boxes, but disagree in regards to edit boxes etc.

An SCLICK event in an editbox would be handy if you wanted to clear text in it when it was clicked on, or some other thing.

A good example of this is having text cleared from a form editbox in a website. It is something that some people want to do (there was a thread in scripts and popups recently asking this same question).

actually looking back im sure someone could find a use for just about any event in any control i realized the same thing with the edit box but decided against editing my post for a 3rd time lol. Most of what you suggested would be easy to add (I think khaled already subclasses editboxes anyway) but id still like to see a few more controls and some more versatility on the pre exisiting ones such as a /did -s to resize specific controls. while were on the subject i think the dialog itself should have a few more events sich as size and move. dialogs should have an option similar to

dialog blah {
Title "dialog" minimize maximize close size
}

so a dialog can have the complete system menu buttons as well as be resizable without the need of mdx or similar dll's

noone of these would be extremly outrageous to add and would make dialogs alot more versatile

(someone has mentioned that dialogs can have caption buttons when opened on the desktop)

You can use mouseover, mousein, and mouseout in mirc. It's true that it's a little more trouble than those specific commands, but it is not that difficult to do (and you could easily script an alias to make those specific commands).

Use $mouse which can allow you to find out if the mouse is in a specific location (rectangle) which can be used for all those commands. Many scripts make use of this command and have notes appear in their dialogs based on what the mouse is over.

how can $mouse be used used to tell when the mouse has left an edit box? or any other control. $mouse only works for the dialog itself and not its controls (unless this has changed recently)

Use $mouse to locate the position of the mouse. Then use:

$inrect(x,y,x,y,w,h)

to find if the mouse is inside the specified location (ie. the location of the edit box or other control).

You can also use $inpoly for this, but most controls are rectangular in nature, so $inrect is easier to use.

the mouse event isnt triggered for controls only for the ddialog. so the mouse will _never_ be inrect of a control when the event is fired. perhaps maybe using a timer while the dialog is open or some other similar method but this would be a real dirty hack as apposed to just having the event fired for a control.

6.02 versions.txt:

Using $mouse is a nasty hack to do the same thing a decently developed mousein/mouseout/mouseover should do, which in my opinion should have been rectified a long time ago.

i wasnt aware of the addition since i havent tried it in a while. i thought i tried using it in the newer version and it didnt work i guess i didnt.

If the $mouse now is set to work with items in a dialog, that's great.

However, regarding $inrect... *YOU* specify the rectangle used, so *YES*, you can use $mouse and $inrect without any problems.

Yes, now that $mouse will do it for you, it's great. But, that way will work just fine and is really not too much of a pain to code if you're making a script that can be used on older versions of mirc that do not support the new $mouse ability.

If you don't believe me, I suppose I could write a sample script. Let me know if you need me to show you how it works. Again, that's for anyone who wants to run their scripts on older mircs (which some people do like having backward compatibility).

without the event firing for a control then it only fires when the mouse is on the dialog. if this is the case then how could the mouse be in a controls rect for inrect to work? but because it does fire for a control then the mouse will be in that particular control when the event occurs so of course inrect would work. if you had a control that was 0 0 50 50 then the mouse event wouldnt even fire while you were in that rect. when it did fire you would be outside that rect so a $inrect(0,0,50,50) would fail. however since it does occur for controls now then hit testing seems pointless. i havent checked but has any of the others been added such as leave drop etc.. for controls?