What is the purpose of the second arg to the Dialog() function?

Started by snowsnowsnow, February 20, 2016, 01:36:22 AM

Previous topic - Next topic

snowsnowsnow

I came across this in code, then looked it up, but the docu is pretty scant.

The function Dialog() takes an optional second argument that, if 0, causes the dialog not to be displayed.

When would one ever do this?  (What is the intended use case?)

td

The second parameter is a user requested feature that makes it possible to create and edit a dialog template using the Dialog Editor in one place, for example, one file, but display it from another place, for example,  a second file.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

snowsnowsnow

It sounds like you are saying this is in the "If you're not the requestor (who, presumably, knows what the purpose of this feature is), then don't worry about it" category, but I am still having trouble visualizing the use-case for this.

It also sounds like the purpose is to allow the dialog editor to still generate that one line of executable code (the one with "ButtonPushed") but not have it do anything.  Couldn't the same thing be accomplished more easily just by having the Dialog Editor generate the code but with a ";" at the beginning of the line?

So, I guess my question boils down to: Is there any difference between:

Code (winbatch) Select
ButtonPushed = Dialog(something,0)

and

Code (winbatch) Select
; ButtonPushed = Dialog(something)


td

Quote from: snowsnowsnow on February 22, 2016, 01:47:01 AM
It sounds like you are saying this is in the "If you're not the requestor (who, presumably, knows what the purpose of this feature is), then don't worry about it" category, but I am still having trouble visualizing the use-case for this.

Not saying that at all.

Quote
It also sounds like the purpose is to allow the dialog editor to still generate that one line of executable code (the one with "ButtonPushed") but not have it do anything.  Couldn't the same thing be accomplished more easily just by having the Dialog Editor generate the code but with a ";" at the beginning of the line?

So, I guess my question boils down to: Is there any difference between:

Code (winbatch) Select
ButtonPushed = Dialog(something,0)

and

Code (winbatch) Select
; ButtonPushed = Dialog(something)


The purpose of this feature isn't about what the Dialog Editor generates.  It is about what WinBatch or more specifically, what WIL does.  Your suggestion wouldn't work because WinBatch does not execute comment lines and the WIL Dialog Editor relies on WinBatch to execute the Dialog function.

Of course, if you prefer to uncomment and recomment the Dialog line before and after editing the dialog template, you are free to do so.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

snowsnowsnow

Now you've got me more confused than ever.

Can you tell me, in simple words that even I can understand, what the difference is between the two forms I've posted above?  What does the ",0" version do that the ";" version doesn't do?

td

Apparently, I incorrectly assumed too much background knowledge.  The standard way to use the Dialog Editor is to create templates in separate files without additional scripting in that file.  The template is then made available to the scripts via a call or include statement and the script has one or more Dialog functions of its own for that template as fits the script author's purposes.  This presents template editing problems because the Dialog Editor uses WIL to load the template and, therefore, cannot edit a dialog template in place without the Dialog function for the template in the same file and not commented out - WIL does not execute comments.   

In other words,  Mr. Wilson created a perfectly good scripting language interpreter so we saw no reason to repeat that effort for the Dialog Editor.  So we made use of the existing interpreter and made it possible for the template to have it's own Dialog function separate form the one used to display the Dialog.  To use a cliché, you can have your cake and eat it too.

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

snowsnowsnow

QuoteApparently, I incorrectly assumed too much background knowledge.

No objection there.  I have no problem admitting that dialogs were never really my thing.  I've used most of the other features of WB, but have never really cottoned to the dialogs.  I know that some of the other posters on this board really have, to the point where their whole programs are just one big dialog.

But the thing is, I have not yet been able to get you to actually say what happens when you run a dialog with the ",0" in there.  Obviously, *something* happens, or else it would be equivalent to just commenting it out, but I'm still wondering what that something is.  It sounds like you are saying that the Dialog Editor needs to run it with the ",0" in order for it to be able to edit it, but I'd like to know how/why that is.

P.S.  I also never really figured out how to use the Dialog Editor in an on-going way.  I.e., it always seemed like once you'd run it once - and gotten the generated code and pasted that into your main script - you could never really go back and use the Editor again.  But I'm sure I've been missing something...

P.P.S.  Where this is all coming from is that I have this library, that I got from this board a million or so years ago (I think it was in 2004) and it contains two calls to Dialog() - the first with the ",0" and a comment that says "Don't display the Dialog" and then another call to Dialog(), later on, without the ",0" and a comment that says "Now display it" (or something like that).  I wondered why the first call is in there.

Maybe the guy who wrote this library used the Dialog Editor to create/edit the dialog, and then combined the DE code into his main code and just forgot to remove the ",0" call???

kdmoyers

This is probably a mistake, but I'll try to explain what the ",0" is for.

First, if you don't use the Dialogs, and the Dialog Editor, stop reading.  This will make no sense to you and have no value to you.  Ignore it.

The ",0" allows you to use the dialog editor to maintain your large and complex dialog screens AND also write code that manipulates the dialog variables before execution.  Because of the ",0" the block of code the dialog editor writes will do nothing, will not pop open the dialog.  You can then add your code that manipulates the dialog variables in some way, and then finally execute the Dialog using ",1"

I use this extensively in my package that does tabbed dialog windows.  Each panel can be edited as if it were a lone dialog.  But they don't execute.  Then my code comes along and merges the dialogs together into a master tabbed dialog, which does execute. 

As Tony says, this lets you get your cake (use the GUI dialog editor) and eat it too (programmatically manipulate the dialog variables).

HTH
-Kirby
The mind is everything; What you think, you become.

snowsnowsnow

You *STILL* haven't explained what the ",0" form does and why it is needed at all.

Note: I"m not saying that it isn't needed.  I'm just saying that no one (yet) has explained why it is and what it actually *DOES*.

JTaylor

Not sure this will help either but...

A Dialog, when it loads, is simply a collection of variables which contains values/parameters used by the Dialog function to create and display a Dialog.    Using the example below, once I load a dialog I can issue something like

    Message("HEY",AskLineJimNumControls)

and it will display 005 for the message.   Specifying 1 as a flag in the Dialog() function will cause WIL to process these variables and take action.  Zero will simply load them to memory and go on its merry way allowing you to manipulate the variables before issuing another Dialog() function to actually make it process the Dialog variables.

To reference Kirby's use case, he may have 5 dialogs that he wants to combine using TABs.   Obviously this doesn't work well in editing  since many of the controls would be sitting on top of each other.  Having to combine them manually each time is a pain.  Obviously one option is to pre-process them and combine them during the packaging of the project.   Another option is that he can load all of them in memory at runtime and then manipulate the Master Dialog by assigning the Control variable values from each dialog to a compatible variable in the Master Dialog and change the NumControls variable so all of them would be read/processed as one Dialog.  He can then issue the Dialog() command as one would normally do to cause the newly tweaked Dialog to process and display as needed.

Hopefully I have this right but maybe someone can correct me if I went wrong at some point.

Jim

Example:

Code (winbatch) Select
AskLineJimFormat=`WWWDLGED,6.1`

AskLineJimCaption=`Text`
AskLineJimX=-01
AskLineJimY=-01
AskLineJimWidth=182
AskLineJimHeight=091
AskLineJimNumControls=005
AskLineJimProcedure=`DEFAULT`
AskLineJimFont=`DEFAULT`
AskLineJimTextColor=`DEFAULT`
AskLineJimBackground=`DEFAULT,6|28|85`
AskLineJimConfig=4513741

AskLineJim001=`007,061,036,012,PUSHBUTTON,DEFAULT,"&Ok",1,2,32,DEFAULT,DEFAULT,DEFAULT`
AskLineJim002=`141,061,036,012,PUSHBUTTON,DEFAULT,"&Cancel",2,3,DEFAULT,DEFAULT,DEFAULT,Default`
AskLineJim003=`007,003,170,040,VARYTEXT,askline_text,"Question?",DEFAULT,4,DEFAULT,"Microsoft Sans Serif|6656|70|34","192|192|192",DEFAULT`
AskLineJim004=`007,045,170,012,EDITBOX,askline_entry,"askline",DEFAULT,1,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
AskLineJim005=`005,075,172,012,STATICTEXT,DEFAULT,"Entry limited to %line_limit% characters.",DEFAULT,5,DEFAULT,"Microsoft Sans Serif|5632|40|34","255|0|0",DEFAULT`

AskLineJimButtonPushed=Dialog("AskLineJim")


td

Quote from: snowsnowsnow on February 23, 2016, 04:56:20 AM
You *STILL* haven't explained what the ",0" form does and why it is needed at all.

Note: I"m not saying that it isn't needed.  I'm just saying that no one (yet) has explained why it is and what it actually *DOES*.

The simple answer: a zero value in the Dialog function's second parameter prevents the WIL interpreter from creating the window associated with the passed in dialog template when it encounters the Dialog function in a script.

The detailed answer:  The WIL DLL has a mechanism whereby an executable that loads the WIL DLL can override any WIL function with it's own version of that function.  The WIL Dialog Editor uses that ability to override WIL's Dialog function so it can obtain the name of the template.  The editor then uses that name along with other WIL interpreter provided services to obtain the numerous values of the dialog, controls, and menus of the template.   The Dialog Editor version of the function notes the value of the Dialog function's second parameter but processes the function in the same way whether or not the value of the second parameter is zero. 

Zero second parameter:
WIL interpreter -> doesn't create the dialog window.
WIL Dialog Editor -> remembers the parameter's value but otherwise ignores the zero value.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade