Feature Request - WIL Dialog Editor

Started by galaara98, October 09, 2014, 01:06:20 PM

Previous topic - Next topic


Now that I buttered up TD in a recent post... saying how I appreciate him so much... Seems like a perfectly appropriate time to ask for something that I am probably the only person that would ever benefit from :) but........

I was wondering if the WIL Dialog Editor's "Open from Clipboard" feature could be adapted to a particular "want" of mine.

I often create a Dailog using the WIL DE, and then paste it into my Winbatch script.  Many times I manipulate the Dialog Defininition Variables values in my script and then at some future moment, Re-open it from Clipboard in the WIL DE.

There are many places where I would like the option to use a dynamic/variable value in the Script Definition variables, of which the WIL DE editor damages on Clipboard input.

In the past, for my own reasons, I often used %variable% in the script, but when I Imported that into the Editor and then Exported it after I did my tweaks, the %variable% was lost (I assume because the WIL DE is actually a mini WIL interpreter itself, and actually calculated the value of the %X% substitution... as "".)
An example of this would be

        MyDialogCaption=`PeopleSearch - v%MyVersion%`

More recently I have changed tactics so I didn't have to re-write several lines of the "pasted" text from the WIL DE.  Now I tend to do all my 'against the rules' variablization (is that a word?) by using Markers that I StrReplace just before the actual Dialog() call.
An Example would be like this
   MyDialogCaption=`PeopleSearch - v<MyVersion>`
   ;ButtonPushed=Dialog("MyDialog")   ; this is a place holder for easier import to and from the WIL Dialog Editor

The reason I do this is there is only one line to fix... 
      Just before I copy from Script to Editor, I must uncomment the ;ButtonPushed=Dialog("MyDialog") line. 
          If I forget, the WIL DE says "the paste is useless"
      After I copy from Editor to Script I Must Comment the ButtonPushed=Dialog("MyDialog") line.
          If I forget the dialog doesn't have the variables "fixed" and
          when you close it, it runs again with the variables "fixed" (because remember there is another Dialog() a few commands later)

this may sound trivial but my current 3 applications I support have several dialogs with more than 125 Controls, and as silly as it sounds you end up having to select from the bottom up, because often I select the dialog code, copy to clipboard and then realize I have "copied to clipboard" the commented line, so I have to uncomment... at the bottom of the dialog, reselect, re-copy to clip, paste into dialog editor.  let's just say, it can be easy to accidentally miss one of the steps.

So I guess the first question is... umm... is there a better way to achieve the results?  and if not really... then.

I was wondering... if it would be possible...  For the WIL Dialog Editor to ...  if the clipboard does not contain Dialog( to just append, literally,
@CRLF : `ButtonPushed=Dialog("` : The Deduced "Variable Name" of the dialog, as determined by the rest of the clipboard : `")`

just that... that would make some coding I do more streamlined.  I can easily manage the paste back into the code from the Dialog Editor... but would love the dialog editor to not tell me 'The clipboard has no valid Dialog in it', if the ONLY thing it cant find is the Dialog Statement itself.



Why not just set the Caption using DialogProcOptions() or WinTitle()?

Any other "Variablization" you do can probably be handled by DialogControlSet(), or some other function, so not sure what you are gaining with the substitution.



This feature doesn't completely resolve your issue but the WIL dialog templates have a seldom used template variable called 'Config', i.e., '<dlg-variable>Config'.  If you set this variables value to 2, the editor will create a special 'Dialog' function call that is used by the WIL Dialog Editor but ignored by WinBatch when you script is actual executed.   The special Editor generated 'Dialog' call has an optional second parameter set to the value 0.  When the WinBatch WIL interpreter encounters the Dialog line with the 0 second parameter, it will ignore the function call and move on to the next line.  However, if you include the line with the special Dialog function call into your clipboard paste, the WIL Dialog Editor will load the dialog.  You place a second Dialog function call without the optional second parameter in your script to actually display the dialog. 

This sounds more complicated than it actually is so here is a do-nothing example:
Code (winbatch) Select


MyDialogCaption=`WIL Dialog 1`
MyDialogConfig=2 ; Instructs the editor to generate a special Dialog function call.


; Only used by the editor
ButtonPushed=Dialog("MyDialog",0) ; WinBatch will not display this dialog.

; This call will display the dialog normally.
ButtonPushed=Dialog("MyDialog") ;  or ButtonPushed=Dialog("MyDialog", 1)
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade


Quote from: JTaylor on October 09, 2014, 09:03:02 PM
Why not just set the Caption using DialogProcOptions() or WinTitle()?

Any other "Variablization" you do can probably be handled by DialogControlSet(), or some other function, so not sure what you are gaining with the substitution.


TheCaption is just an obvious place to understand it.

I play all kinds of tricks with variablization of Dialogs

Like (in a menu)
MyDialog051=`000,000,000,000,MENUITEM,"MENU_Help","MENU_HelpTop","Help (v<MyVersion>)",DEFAULT,10,DEFAULT`

or a DropBox

or any control to dynamically control Font on the way in (doesn't seem to be easy to change fonts after creation.. but at least i can change it just before dialog creation)
MyDialog004=`043,051,230,012,EDITBOX,"EditBox_1",ebVariable1,"Edit 1",DEFAULT,40,DEFAULT,"<EditBox_1_Font>",DEFAULT,DEFAULT`

TD.. that Worked!
    for me... again the goal was to not have to do tricks to import/export with the Dialog Editor
AHHHH that was so easy.. i remember that from the old Dialog Editor.. it use to make that choice (of useless or usable dialog) mroe prevalent and i always thought why the crap would anyone make a "Useless" Dialog?