Dialog Workshop : variables

mdj · July 29, 2017, 5:04am

Hi,

I’ve created a form with popup menus that I would like to use as a dialog.

I’ve named them “dField1” and “dField2”, where “Field1” and “Field2” are fields in a record.

The Dialog Workshop generates this code:

loop
    rundialog
       “Form="Entry_Dialog"
        Movable=yes
        Menus=normal
        WindowTitle={Entry_Dialog}
        Height=780 Width=965
        AutoEdit="CELL"
    stoploopif info("trigger")="Dialog.Close"
    if info("trigger")="Button.OK" // Push Button
        // your code here
    endif
while forever

Note that it does not add the corresponding:

Variable: "dField1=Field1"
Variable: "dField2=Field2"

code that the samples in the documentation shows. And, because of that, the dialog does not function as expected.

If I manually add the “Variable” entities, then the dialog works as expected.

The form I’m working on has quite a few popups, so it would be nice if the Dialog Workshop added all those variables “automagically”.

Am I doing anything wrong here? Or is this a known item of the Dialog Workshop?

TIA,

– Mark

admin · July 29, 2017, 7:40am

I’m so happy to hear that I am not the only person in the world that uses the Dialog Workshop! Actually, I use it quite frequently, I even just used it earlier today.

The dialog workshop generates skeletal code as a starting point. It was never claimed that it would write every last line of code for you. It definitely doesn’t scan your existing code and/or form objects and use AI to notice that you have defined variables that are one letter different than some field names.

However, look on the bright side – using the Variable option saves you quite a bit of typing over manually entering the code to do these assignments. If you coded this manually you’d have to type all of the assignments twice (in forward and reverse order). I got tired of doing that so I added the Variable option. Actually, it might be nice to have another option where you could simply give a list of fields and a prefix, that would be even less typing. But not zero. Hmm, in Panorama X maybe you could just give it is prefix and it could scan the form objects for text editors with that prefix followed by a field name. And the Constructor will construct the objects for you that way. A nice daydream for sometime in the future.

RAmeeti · July 29, 2017, 11:27am

And perhaps the Preferences could allow the user to specify the prefix to be used for types of objects.

mdj · July 30, 2017, 4:50am

Heh. I understand.

The Dialog Workshop is way cool.

Why not just scan all the objects for variables beginning with “d” (or a user-configurable prefix, as suggested by RAmeeti)? (Currently, you just look in TESO objects, right?)

That way, the “Variables” settings are completely driven by the data in the form. No AI required …

Anyway - it’s all fixed for now.

Thanks, as always, for the prompt response!

– Mark

mdj · July 30, 2017, 5:17am

One more question:

If I have an “OK” button, and it’s attribute is “Default Button”, is there a way to trigger it when the “Return” key is typed?

I realize there’s a possible conflict with a TESO object … but maybe there’s a way to cleanly trap the return key?

TIA,

– Mark

admin · July 30, 2017, 7:29am

In Panorama X, that “Just Works™”

It can be done in Panorama 6 also, but I’ve forgotten the details

I don’t understand what this means?

I guess Mark understood it though. However, I still don’t.

I do? Who remembers?

Ok, I looked at the code. It appears that in Panorama 6 it is looking at TESO, Popup Menu, Data Buttons, Sticky Push Buttons, and Text Lists. In Panorama X it should work with any type of object that references a field name. And my comments earlier about AI were wrong – it should work if the prefix is d. (Maybe Robert’s suggestion is that somehow other prefix values should be allowed? If so, it looks like the writedialogcode statement in Panorama X does allow this, though I don’t think the Dialog Workshop UI supports this currently. I still don’t know what “types of objects” refers to in this sentence. There’s just one prefix, no matter what the object type is.)

Circling back, I don’t think I really understood your (Mark’s) original question, and I didn’t really remember how this feature worked, either. There is definitely a bug in the Panorama 6 version, and it should have generated the Variable: items for you, as you thought originally. In fact, I see that it is documented that it will do that, on page 502 of Formulas & Programming. That’s probably how you knew about it

The code for writedialogcode is open source, and I was hoping that maybe I could give you a source level patch you could apply yourself, but it looks like the bug is in a low level function, not in the source you have access to. So I don’t think this will ever work in Panorama 6.

For the future, the good news is that I have verified that Panorama X does NOT have this bug, it correctly generates the Variable: item for a pop-up menu.

mdj · July 30, 2017, 9:56pm

LOL!

Yes, I actually read the documentation (this time!) before asking.

Thank you for digging into the “old code”.

I have addressed the “Variable:” issue.

I guess I need to figure out the “Default OK” button … or not worry about it.

Thanks!!!

– Mark0

admin · July 30, 2017, 11:17pm

Ok, I did a bit more digging into the old code. The rundialog statement sets up a hotkey for the Enter key, so that pressing the Enter key is the same as clicking the Ok button. It doesn’t do that for the Return key though. I think that adding this code to the dialog initialization code might do it.

«HotKey[24]»={global dlgStack define dlgStack,"" local s,cb cb="Button."+tagparameter(array(dlgStack,1,chr(1)),"okbutton=",1) if cb="" rtn endif settrigger cb resume s}

Warning – I have not tested this. I just took the line of code from rundialog that does this for the Enter key and changed «HotKey[4C» to «HotKey[24». It’s possible that there is some interaction with Text Editor objects that will cause this not to work, but I think there is a good chance it will work.

mdj · July 31, 2017, 5:08am

Hi Jim,

Cool. Thanks. I’ll give that a try.

In the meantime, I wrote the following that will generate the: {Variable: “dField=Field”} items.
Not that I need it anymore … but it was bugging me. LOL!
I might add it to the Dialog Workshop … maybe … one day …

@RAmeeti: you could use this to allow variables with different prefixes. (I think. I have not tested it. )

Here’s the output generated by the code below:

Variable : "dKey=Key"
Variable : "dValue=Value"
Variable : "dList=List"
Variable : "dButton=Button"
Variable : "dButton=Button"
Variable : "dDataButton=DataButton"
Variable : "dDataButton=DataButton"

And with the extra debugging output, you get this:

ID: 686:SuperObject:PopUp Menu - Variable : "dKey=Key"
ID: 876:SuperObject:Text Editor - Variable : "dValue=Value"
ID: 1048:SuperObject:Text List - Variable : "dList=List"
ID: 1302:SuperObject:Sticky Push Button - Variable : "dButton=Button"
ID: 1522:SuperObject:Sticky Push Button - Variable : "dButton=Button"
ID: 1742:SuperObject:Data Button - Variable : "dDataButton=DataButton"
ID: 1990:SuperObject:Data Button - Variable : "dDataButton=DataButton"

Enjoy!

– Mark

In this code, the following assumptions are made:

A database with two fields: “Key” and “Value” is assumed.
There is a record with a “Key” value of “datatypes”.

That’s where the resulting data ends up. It displays nicely in a TDSO.
However, it can be used in a variety of ways and this code is provided “as-is”.
(I have no idea where I picked up the habit of prefixing local variables with “lv” … it can be both annoying and helpful. )

Hmm … it’d be nice if a TDSO included a flag to enable/disable selecting and copying text out of it.
Yeah, I know, a TESO will do the job.

local lvVar, lvObjID, lvObjNum, lvObjName, lvObjType, lvFieldOrVariable

lvVar = ""
lvObjNum = 1

selectallobjects
loop
    objectnumber lvObjNum
    stoploopif (not info("found"))
 
    lvObjID = str(objectinfo("id"))
    lvObjType = objectinfo("type")
    lvObjName = objectinfo("name")
    
    if lvObjType contains "SuperObject"
        case lvObjType contains "Text Editor"
            lvFieldOrVariable = objectinfo("#FORMULA")
        case lvObjType contains "Sticky Push Button"
            lvFieldOrVariable = objectinfo("#FORMULA")
        case lvObjType contains "Data Button"
            lvFieldOrVariable = objectinfo("#FORMULA")
        case lvObjType contains "PopUp Menu"
            lvFieldOrVariable = str(objectinfo("#FIELD"))
        case lvObjType contains "Text List"
            lvFieldOrVariable = str(objectinfo("#FIELD"))
        defaultcase
            lvFieldOrVariable = ""
        endcase

        // The variable prefix could be changed to look for something other than "d"
        if lvFieldOrVariable beginswith "d"
            //Uncomment the following for more debugging information
            //lvVar = lvVar + "ID: " + lvObjID + ":"+lvObjType+" - "
            lvVar = lvVar + "Variable : " + {"} + lvFieldOrVariable + "=" + lvFieldOrVariable[2,-1] + {"} + ¶
        endif
    endif

    lvObjNum = lvObjNum + 1
while forever

// Put the result somewhere - this assumes two fields: "Key" and "Value"
// Selects the record where "Key" = "datatypes"
// And puts the Variable value in the field called "Value"

select Key = "datatypes"
Value = lvVar

admin · July 31, 2017, 6:31am

In Panorama X, there is such a flag! And I used it in the Dialog Workshop

mdj · July 31, 2017, 2:01pm

Ok. I feel silly, now.

I just (re-)discovered the Panorama extensions …
and found the definition of WriteDialogCode in the _DialogAlertLib extension …

Instead of struggling through and writing the code, above, I could’ve just plagiarized!

@RAmeeti: you could modify the _DialogAlertLib to use different variable prefixes. It’s all setup … just modify the variable dPrefix. Or, probably better and safer, copy the code into your own library and use that instead.

D’oh!

– Mark