mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline OP
Hoopy frood
OP Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
I have a dialog that I'm working on (it's fairly lengthy so I won't post the code unless I have to), but the current problem I'm encountering is the enabling/disabling of a set of buttons.

The button ID's are stored in a variable to make it easy to enable/disable all of them at one time.
I have another button which is separate from the group, but positioned in the dialog in the same area as the group.
When I have this last button displayed it works perfectly with
Code:
on *:dialog:DJ:sclick:17:{
  did $iif($did(71).enabled,-b,-e) $dname %sched.am
}

however, having it displayed ruins the visual look of the dialog, so I tried hiding the button, which makes the dialog look good, yet it also seems to stop working in the code as previously posted.

Any ideas as to why this is happening and/or how I can get around it and still have my dialog look the way I want?

Joined: Jun 2008
Posts: 48
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Jun 2008
Posts: 48
I dont think I totally understand the problem. Are you trying to hide the button and still have it work?

I'm just wondering if using something like a $inrect($mouse.x,$mouse.y,#,#,#,#) in your dialogs sclick event to track the click and act like a button was pressed would work for you or not but I may not even understand what it is you want.

I used the same kind of thing in my ViewPic photo album to track clicks on photos because sometimes a picture file wouldnt be displayable but I still wanted the area selectable so they could delete the file that couldnt be displayed.
Heres a peice of the code from my script Typo's ViewPic.
Code:
if ($did == 0) || ($did isnum 24-39) {
    if ($inrect($mouse.x,$mouse.y,10,106,72,78)) { var %ViewPicSelected 6 }
    if ($inrect($mouse.x,$mouse.y,96,106,72,78)) { var %ViewPicSelected 7 }

If this isn't the kind of idea you needed then please try and help me understand your problem better.


I've gone to look for myself. If I should return before I get back, please keep me here.
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline OP
Hoopy frood
OP Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
Are you trying to hide the button and still have it work? - yes

I shouldn't have to use $inrect, as that's a picture window reference, not a dialog reference.

To my knowledge, a hidden button should still work, if the area where the button is located is clicked (and it does work that way for my default button, which is also hidden). The button isn't disabled, just hidden from view.

Joined: Jun 2008
Posts: 48
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Jun 2008
Posts: 48
While $inrect was probably introduced for picwins it is definately not limited to them. It can be quite handy in any instance you want to track a mouse movement inside of a specefied area.

That being said I went ahead and made a small dialog to test this because as far as I could remember, hiding a bitton disables it. In my test I reached the same results. Even if the button was the default one, hiding it made it stop responding. No matter where I clicked all that was returned was an sclick of 0.

The code I used for the test is:
Code:
dialog test123 {
  title "Testing"
  size -1 -1 82 51
  option dbu
  button "Default", 1, 23 30 37 12
  button "1", 2, 23 30 37 12, hide
  button "3", 3, 23 12 37 12
  button "4", 4, 23 12 37 12, hide
}
on *:dialog:test123:sclick:*:{ echo -s $dname $did $devent }

I also used /did commands to hide and make visible all the ids indivudally while I was testing but when a button was hidden and no other button was left visible under it, I got "test123 0 sclick" for the "$dname $did $devent".

I personally don't know how else you can possibly check for a click somewhere that buttons are being hidden other than unhiding them or actually tracking the position of a mouseclick in the same area.

If you decide to try that just remember to make it react when the mouse movements are in the specefied area, whether you manually code it or use $inrect, and when $did == 0 so that you know all the buttons that would normally function are hidden without having to check them individually. If any button is visible then the sclicks $did will not == 0 due to it actually clicking a button that had its own id.

Anyhow, thats my idea, maybe someone else will have a better one.

Good luck.


I've gone to look for myself. If I should return before I get back, please keep me here.
Joined: Mar 2003
Posts: 612
B
Fjord artisan
Offline
Fjord artisan
B
Joined: Mar 2003
Posts: 612
Any way you could make it a "button 17, 0 0 0 0"
type affair so you can't actually see it but can still use it in the script?

How are you activating the sclick if it's hidden? Just hoping to click on the area of the dialog in which it lay or is it being scripted? Would it be possible to instead make it flat with no label - sized in a way that looks hidden?

btk



billythekid
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline OP
Hoopy frood
OP Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252

Having the button in that format, would mean that the button size is 0, as you said, not visible, but there'd also be no area for the sclick to register.
The location of the button matches the heading of a dialog box, which is visible and enabled at all times.
Ideally I would've liked to have been able to click on the heading of that box, which, in turn, would enable all of the ID's that are located in that box, however, I was unable to get the sclick event to register for the box, and the help documentation states
Quote:
sclick single click in list/combo box, or check/uncheck of radio/check buttons, or click of a button.

Thus brought up the idea of having an enabled, but hidden, button located at the same physical location as the box heading.
Since the heading is located a little bit down and to the right of the top-left corner of the actual box, the x&y co-ordinates don't conflict.

Dialog layout code has been pasted here

Note that there are two icon images in the dialog, so if you go to test the layout, remember to remark or remove those lines.

Last edited by RusselB; 21/09/08 11:32 PM.
Joined: Jun 2008
Posts: 48
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Jun 2008
Posts: 48
I still think my idea is the best solution. It's simple, works and just plain makes sense. You want to know when an areas is clicked without having a button visible so just lose the button and track the sclick yourself.

I loaded your dialog with the icon lines omitted and tossed this code in and it worked great tracking the clicks in those areas only.
Code:
on *:dialog:dj:sclick:*:{ 
  if ($inrect($mouse.x,$mouse.y,21,225,75,25)) { echo -s Success 1 }
  if ($inrect($mouse.x,$mouse.y,300,223,75,25)) { echo -s Success 2 } 
}

I really have a hard time understanding why I give you a perfectly good solution and you basically just don't want to use it.

The $mouse and related identifiers/commands may be listed with the picwin information but they are by no means limited to that.

Good luck.


I've gone to look for myself. If I should return before I get back, please keep me here.
Joined: Oct 2005
Posts: 1,741
G
Hoopy frood
Offline
Hoopy frood
G
Joined: Oct 2005
Posts: 1,741
The sclick event is also activated when you click anywhere on the dialog surface. When you click on a portion of the dialog that is occupied by a BOX dialog object, it is registered as sclick on $did 0. As mentioned above, you can use the $inrect identifier to determine if the click falls within the rectangular area you are monitoring. The only problem I can foresee with this method is that the $inrect identifier uses pixels, and dialogs are usually made in dbu. Here is a sample using a pixel-based dialog:

Code:

alias test dialog -mv test test
dialog test {
  title "testing"
  size 100 100 -1 -1
  option pixels
  box "Testing", 10, 10 10 100 100
}
on *:DIALOG:test:sclick:0:{
  echo -a > $inrect($mouse.x,$mouse.y,20,12,35,10)
}



/test

Click on the dialog window.

-genius_at_work

Joined: Jun 2008
Posts: 48
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Jun 2008
Posts: 48
Be carefull using a $did of 0 only as if the user clicks on the words of the box or another id in the area it will pick up the box's id and so would not have a $did of 0. Thats why I used * in my example tho with a little checking you could find all possible id's that will fall in the area.


I've gone to look for myself. If I should return before I get back, please keep me here.
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline OP
Hoopy frood
OP Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
Thanks for all the help, and I didn't mean to imply that your solution, Typo, wasn't great, it is.

Basically I'm just being a bit frustrated that a hidden object in a dialog is automatically a disabled item.

Joined: Oct 2005
Posts: 1,741
G
Hoopy frood
Offline
Hoopy frood
G
Joined: Oct 2005
Posts: 1,741
BOX dialog objects don't generate an sclick event of their own. They show up as sclick on $did 0.

-genius_at_work

Joined: Aug 2004
Posts: 7,252
R
RusselB Offline OP
Hoopy frood
OP Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
Quote:
The only problem I can foresee with this method is that the $inrect identifier uses pixels, and dialogs are usually made in dbu.
Fortunately, this dialog, and most of the others that I do use and create, use pixels, as I find they give me greater accuracy for positioning items that I want close together.

Joined: Jun 2008
Posts: 48
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Jun 2008
Posts: 48
Ya know, I always wondered if there was an advantage to using pixels. Giving me more control is something I would consider very advantagous so I think on that note I'm going to have to start using pixels instead of dbu's.

I have to be honest, I've never seen dbu's do what they were supposed to do anyhow which is to make a dialog appear the same on all monitors. $dbuw and $dubh seem to always return 2 so I honestly dont get the point of dbu's anyway.


I've gone to look for myself. If I should return before I get back, please keep me here.
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline OP
Hoopy frood
OP Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
You can add to that information, if you want, the fact that I use 3 different monitors and even using pixels I can't see much, if any, difference looking at the same dialog on any of my monitors compard to any of my other monitors.

Joined: Jun 2008
Posts: 48
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Jun 2008
Posts: 48
I actually meant resolutions not monitors. Are those monitors running different resolutions? The mirc file says
Quote:
The dbu option makes mIRC use dialog base units when creating the dialog, this ensures that the dialog will look the same for all users under any size display, etc. Pixels is the default however to maintain compatibility with previous scripts.
but when I change resolutions to every resolution my laptop supports dbuw and dbuh always = 2.

I've just always wondered why it doesn't do what its supposed to. It would be great to know that something that fills 1/4 the screen on someones monitor at 800X600 would take the same amount of space on someone elses running at 1280x1024 but it just doesn't work that way even tho its supposed to.

I'm wondering if someone may know something I don't or if I'm right and DBU's are completely useless.


I've gone to look for myself. If I should return before I get back, please keep me here.
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Quote:
I've just always wondered why it doesn't do what its supposed to. It would be great to know that something that fills 1/4 the screen on someones monitor at 800X600 would take the same amount of space on someone elses running at 1280x1024 but it just doesn't work that way even tho its supposed to.

That's not what DBUs are supposed to do. "look the same" refers to the way controls within the dialog are displayed under different resolutions and different font sizes: in Windows' Display options, you can adjust the font size (DPI) of displayed text. If your dialog uses pixels, some of the text may not fit in the dialog under some combination of resolution and DPI and will be chopped. Using DBUs ensures that this will never happen.

For more information, Google "dialog base units".


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Jun 2008
Posts: 48
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Jun 2008
Posts: 48
Thanks for your reply qwerty and your explanation helps dbu's in general make sense but I still have to wonder why $dbuw and $dbuh always remain the same in mirc?

Mirc says that "The identifiers $dbuw and $dbuh return the dbu per pixel width and height values for the current display.".

It makes it look like dbu's wouldn't actually do anything since the number is never changing at any resolution that I've tried, its always 2.


I've gone to look for myself. If I should return before I get back, please keep me here.
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Key words in my previous posts are "font size". Did you try changing the DPI, rebooting and checking $dbuw/h again?


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Jun 2008
Posts: 48
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Jun 2008
Posts: 48
Thanks again qwerty, changing to 120dpi and rebooting showed a $dbuw and $dbuh of 2.5 instead of 2.

The part that got me is that changing the font size in the appearance section of the display properties wasn't enough.

I tried that when you said font the first time and it does increas the font size but doesnt affect the dbu results. It was going into advanced and actually changing the dpi and rebooting that finally did it.

Thanks again, now i know. smile


I've gone to look for myself. If I should return before I get back, please keep me here.

Link Copied to Clipboard