Forums Feature Suggestions General Dialog Suggestions

Here are some general dialog suggestions that have probably been posted before:

(1) Allow the dialogs to be minimized to the status bar, or even better, and special (disablable) dialog bar.

(2) Allow for resizing and repositioning of controls at runtime

(3) Allow for no titlebar/control box

Regards,

By definition, a dialog:
- Can't be maximized or minimized
- Can't be resized

A window with no titlebar looses a lot of functionalities: moving, etc

Well, dynamic resizing of *controls* would be an interesting feature in combination with functions like $width or $height...

Now, I wonder why $did() has no x/y/width/height property - personally I'd like to use them to write more intelligent mouseover event handlers.

$did() doesn't need .x/.y/.w/.h because you already KNOW exactly how large they are because YOU defined the dialog table definition. I suppose if you really needed to make that information "retrievable", you could put all the values into a hash table so you could refer back to them later.

Code:

;  MyDialog Edit controls
alias MDe {
  if ($isid) return $hget(MyDialog,$+(edit,$1,.,$2))
  hadd MyDialog $+(edit,$1,.,$2) $3-
}
on *:LOAD:{
  hmake MyDialog 25
  
  hadd MyDialog option dbu
  hadd MyDialog title This is the topic of my fancy dialog
  hadd MyDialog size -1 -1 300 300
  
  MDe Name Text Stuff in editbox here!
  MDe Name ID 9
  MDe Name x 4
  MDe Name y 4
  MDe Name w 2
  MDe Name h 4
  MDe Name styles multi return result
  ;  etc.
  
  hsave MyDialog MyDialog.cnf
}
on *:START: if (
dialog MyDialog {
  option $hget(MyDialog,option)
  title $hget(MyDialog,title)
  size $hget(MyDialog,size)

  edit $MDe(Name,Text) , $MDe(Name,ID) , $MDe(Name,x) $MDe(Name,y) $MDe(Name,w) $MDe(Name,h) , $MDe(Name,styles)
  edit $MDe(Addy,Text) , $MDe(Addy,ID) , $MDe(Addy,x) $MDe(Addy,y) $MDe(Addy,w) $MDe(Addy,h) , $MDe(Addy,styles)
  edit $MDe(Phone,Text) , $MDe(Phone,ID) , $MDe(Phone,x) $MDe(Phone,y) $MDe(Phone,w) $MDe(Phone,h) , $MDe(Phone,styles)
}

You could use $MDe(<editbox name>,<x|y|w|h|Text|ID|styles>] to retrieve the information you need for your mouse stuff then. You would add little aliases like [/|$]MDe to shorten your code or just leave it long for the production code. (I have shortened it to present it better on this forum, but it's not needed.)

Thanks for the prompt reply.

I see two disadvantages to the method you suggest:

• The dialog is not easily editable, thus it is a pain to maintain it, when you want to move an item for example.
  
• Hash Tables use more resources, right?
  

What I had in mind was to set a tokenized list of ids which i had interest in and fetch each id's .x/.y/.w/.h property and then use $inrect() to test $mouse.x/.y for the mouseover effect.

Thanks for your input anyway, I'll have it printed for reference...

Code:

on *:START: if (
dialog MyDialog { 

Err.. There's something missing, isn't it?

In reverse order:


Yes, I was going to have it loadup the hashtable on START but never finished typing it.


Yes and no. They are faster than variables or .ini files but they do take up some RAM (they're kept in active memory which is why they are so fast.)


Quite the reverse is true, here. The values would more easily be changable on-the-fly. Mind you, you would probably want to alter the values stored in the hash table through script. But it would make editing the positions of the dialog easier because you wouldn't have to actually go into the script to change the values of the dialog table definition. You could type it out manually if you so chose, or alias it, or put it in a popup or whatever you wanted.

For instance: suppose you had a dialog with several things on it and you wanted to be able to have it load up in 3 different sizes. Some people like their controls cramped and very small, some like large buttons with baloons and happy faces on them. You could define a menu item to make your dialog show in 3 different sizes by simply changing the values stored in the hash table and recreating the dialog instance (dialog -x $dname | dialog -m $dname). The new values would be used to resize everything. dialog -s $dname wouldn't work here because it would only resize the dialog form itself, not the rest of the controls which would need to be reread and recreated.

As far as actually editing the data, you might want another dialog to examine the data and maybe present it to you in a more human-friendly manner. Or simply have different aliases that write preset data sets into the "live" data positions. For instance, you might have 3 completely different sets of table def parameters: small, normal, large. Each of them would copy their data into the "live" version stored in the manner posted earlier. You'd probably switch them by an alias, copying over the values stored "live" with those stored in the selected size. Each control's position and size is still easily retrievable in script.

Having said all this, I agree it could be made considerably easier:

• [color:#000000]$did($dname,N).x
• $did($dname,N).y
• $did($dname,N).w
• $did($dname,N).h
• $did($dname,N).styles
• $did($dname,N).type (text/edit/button/check/radio/box/scroll/list/combo/link/tab/menu/item)
• did -s $dname ID x y w h (to resize it on the fly without having to re-create the form)
• edit "" , ID, x y w h, right center multi pass read return hsbar vsbar autohs autovs limit N, [%saveVar | htable hitem]

[/color]All these are cool ideas, though I must be honest and say that I'm not sure that I, personally, would ever need some of them...but who knows? I'm pretty sure once scripters got used to the htable hitem way of saving item state/values automatically, that would be MUCH easier (and cleaner) than doing it all manually on close..it already does variables, according to the help file (I have not tested that yet - I wonder if it works for all controls).