Forums Scripts & Popups Hidden dialog button question

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
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?

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.

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

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.

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:

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.

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

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
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.

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.

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.

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:



/test

Click on the dialog window.

-genius_at_work

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.

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.

BOX dialog objects don't generate an sclick event of their own. They show up as sclick on $did 0.

-genius_at_work

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.

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.

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.

I actually meant resolutions not monitors. Are those monitors running different resolutions? The mirc file says
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.

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".

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.

Key words in my previous posts are "font size". Did you try changing the DPI, rebooting and checking $dbuw/h again?

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.