Prevent dialog focus from changing - mIRC Discussion Forums

Currently I have some 3 state checkboxes. When the checkbox is clicked the 2nd time (indeterminate state) then an edit box opens allowing for a single number to be entered. This works fine, however, it is possible for someone to click another checkbox to that state without entering a number in the edit box that has already been opened. Is it possible to force the user to fill in the numeric for the edit box before allowing the other change (ie: maximum of 1 edit box open at a time). I suppose that I could disable the rest of the dialog until the information has been entered, but if there's another option, I wouldn't mind trying it.

Does a modal $dialog() as the entry box work?

(Haven't tried it, but that's my understanding of modals. I'm probably wrong

Then we have a discrepancy in our understanding, as the help file states

Quote:

they halt the script until the dialog is closed

I don't want the dialog to have to close, just force the person to make an entry in the edit box before another edit box can be opened (aka made visible)

I think Sais meant that rather than having an editable editbox on the main dialog for when someone does something which requires a text entry, you could open a separate $dialog (or $input) for the person to type in, and then have their entry displayed in a read-only box. You could use the same $dialog (or $input) code, and just store the $result in a different place for each case.

-genius_at_work

oh...well, maybe I'm doing something wrong, but when I use the $dialog I don't get any place to enter the information, and when I use $input I don't have the control that I've obtained using a 1 character limited editbox (also I don't care for the fact that when the input box is closed, I still have to click the taskbar for the dialog to show up again...dialog is created using the -md switches)

$dialog() will open a custom dialog and won't let any other window retrieve focus until it's closed. In other words you'd have to make your own custom dialog like $input() with a 1 character limit editbox, it won't be done for you. It offers more control but means more work.

Thanks...this is beginning to sound like it's going to be more trouble than it's worth.

This may be what you're after, but is obviously not built into your dialog. It's just an example, so let me know if there's part of the code you don't understand.

Code:

dialog blah {
  title "For RusselB"
  size -1 -1 52 41
  option dbu
  check "1", 1, 3 5 16 10
  edit "", 2, 23 5 8 10, hide limit 1
  check "2", 3, 3 17 17 10
  edit "", 4, 23 17 8 10, hide limit 1
  check "3", 5, 3 29 18 10
  edit "", 6, 23 29 8 10, hide limit 1
}

on *:dialog:blah:sclick:*:{
  if ($did == 1) { 
    if ($did(1).state) { 
      if (($did(4).visible) || ($did(6).visible)) { did -u $dname 1 }
      elseif ((!$did(4).visible) && (!$did(6).visible)) { did -v $dname 2 }
    }
    else { did -h $dname 2 }
  }
  elseif ($did == 3) { 
    if ($did(3).state) { 
      if (($did(2).visible) || ($did(6).visible)) { did -u $dname 3 }
      elseif ((!$did(2).visible) && (!$did(6).visible)) { did -v $dname 4 }
    }
    else { did -h $dname 4 }
  }
  elseif ($did == 5) { 
    if ($did(5).state) { 
      if (($did(2).visible) || ($did(4).visible)) { did -u $dname 5 }
      elseif ((!$did(2).visible) && (!$did(4).visible)) { did -v $dname 6 }
    }
    else { did -h $dname 6 }
  }
}

/dialog -m blah blah

If that's not what you want then I've probably misunderstood.

Thanks anyways Hixxy, but I've managed to resolve the problem by checking the enabled state of each id in my dialog, and storing the one's that are enabled in a comma separated variable, then using that variable in a disable command to temporarily disable all ID's in the dialog except the one that is represented by the edit box that I'm working with.

Quickly looking at your code, I see that it uses about 24 lines for 3 check boxes, doing a comparison of two edit boxes for each check box. Since my code has 36 check boxes, I'd estimate that I'd've need another 288 lines of code. By doing it the way I have, I had to add 21 lines... While shorter isn't always better, in this case I think it is.

Indeed it is. Without seeing the full dialog that's the best I could do for you.

Glad you got it sorted anyway

I didn't want to post the full script, seeing as how it's currently 360 lines, and there's still a fair bit to do. When it's complete, I'll post a link to it and people can let me know what they think.

Please do post a link to it.. ? I would like to see it if i could. I have written many complex dialogs, and i too have had to exit the realm of "pretty" to get things to work properly. Sometimes you cant escape length to eliminate error routes. I know exactly what you mean. I notice you have a different style in coding them than i use. I wouldn't mind taking a look at how you have things set up in something that is a little more complex.

I'm always looking for a way to shorten stuff up...

Thanx

Estimating completion of the dialog, with testing and posted, on or before next Monday. In the meantime, if you want to take a look at some other dialogs and scripts that I've written and posted already, follow this link