The Origin Forum
File Exchange
Try Origin for Free
The Origin Forum
Home | Profile | Register | Active Topics | Members | Search | FAQ | Send File to Tech support
 All Forums
 Origin Forum for Programming
 Forum for Origin C
 Dialog Builder and Initialization

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Anti-Spam Code:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkUpload FileInsert Image Insert CodeInsert QuoteInsert List
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

 
Check here to subscribe to this topic.
   

T O P I C    R E V I E W
dlw21 Posted - 10/21/2002 : 1:50:39 PM
Hello,

I have some questions about the order of "events" in process of executing a dialog built from dialog builder. I am using OriginPro 7 SR2 and Visual C++ v6.0, both under Windows XP Pro.

I've created a dialog that includes several edit boxes. I'd like these boxes to be filled with values when the user starts it up. To this end, I have inserted some script in the OnInit section of the .OGS file generated by the DB wizard, as per the advice of the documentation. Everything *seems* to work OK, except for a few idiosyncrasies I'd like someone to explain in greater detail.

First, I found that the OnInit section gets run twice when the dialog.start() is executed. Why is this? This wouldn't be a huge problem, except for my next question.

Second, it appears that the first time OnInit is run, the variables associated with the edit boxes are NOT defined in the LabTalk environment. I found that the second time OnInit is run, they ARE defined. Thus, all is not lost -- I can initialize the edit boxes the second time around. To avoid generating error messages, I wrap the initialization with an exist()==4 test to make sure it executes only the second time. Again, can someone explain what is going on here?

Next, I found that the dialog remembers the values from the previous time it was opened. It looks like the .OPS file origin produces for the dialog is where those settings are remembered. Is there a way to suppress those values and make sure my own initialization is always used?

One logical answer seemed to be to delete the .OPS file. While it did remove the memory of the previous values, it also had an odd side effect: now both times OnInit ran, the variables were undefined! The dialog pops up looking OK, but no initialization has occurred! How can I avoid this problem?

TIA,
Dave

3   L A T E S T    R E P L I E S    (Newest First)
dlw21 Posted - 10/22/2002 : 2:59:18 PM
Mike and Gary,

Thanks so much for your advise. It makes a lot more sense now. The tab placeholder does in fact have an -I option, but I didn't make the connection until now.

The -N options sounds right up my alley, too.

Dave

Gary Lane Posted - 10/21/2002 : 5:37:59 PM
Hi Dave and Mike,

Yes...and thanks.

-N on the string table entry for the dialog should prevent the entire dialog from recording changes while -N on an individual control prevents just that control from recording changes to the SET section of the OPS file.

Without seeing your resource file I bet you are using the -I switch on your main dialog? This causes the initialization process to run twice - once through for all pages of the dialog and then once again for only the active page. The -I switch is used to initialize all pages of the dialog and then the active page again so that all controls on all pages can be immediately accessed before the user actually visits each page using the GUI. This allows programatic access to controls on later pages before leaving the first page.

To illustrate, I added a LabTalk type -a <SectionName>; command to all initialization sections in LR.OGS and LR.OPS (some of which I had to specially create just for this illustration) which together control the Origin Linear Fit (Regression) Tool. The following list shows the order of execution with comments added by me.

OnInit // OGS OnInit for dialog 1st time
Tab.Operation.PREPARE // OPS Prepare for Operation tab 1st time
Tab.Operation.OnInit // OGS OnInit for Operation tab 1st time
Tab.Operation.SET // OPS Set for Operation tab 1st time
Tab.Settings.PREPARE // OPS Prepare for Settings tab only time
Tab.Settings.OnInit // OGS OnInit for Settings tab only time
Tab.Settings.SET // OPS Set for Settings tab only time
OnInit // OGS OnInit for dialog 2nd time
Tab.Operation.OnInit // OGS OnInit for Operation tab 2nd time
Tab.Operation.SET // OPS Set for Operation tab 2nd time
Tab.Operation.Active // OGS Active for Operation tab only time

I hope this helps.

Gary



Edited by - Gary Lane on 10/22/2002 2:35:01 PM
Mike Buess Posted - 10/21/2002 : 5:02:16 PM
Hi Dave,

I haven't ran across your first two observations, but you can avoid the final problem by using the -N switch in the main string table entry.

IDD_MYDIALOG...100...MyDialog -N

As far as I can tell this makes the entire dialog nonrecordable.

...You might need to delete the OPS file once more before you try it out.



Mike Buess
Origin WebRing Member

Edited by - Mike Buess on 10/21/2002 5:03:51 PM

The Origin Forum © 2020 Originlab Corporation Go To Top Of Page
Snitz Forums 2000