PBForms BEGIN/END DIALOG feature

[Chris Holbrook]

I just noticed that when editing a PBForms app that the statement which I had inserted after DIALOG NEW was discarded. In fact this was a macro including a setprop statement, the purpose of which was to pass a value from the dialog proc to the callback proc, which the callback could pick up in its WM_INITDIALOG handler.

Is there any setting or strategy by which I can talk PBForms into not doing this.

If not, from a design point of view, would it not be better to alllow "user code" to be inserted between the DIALOG NEW and CONTROL ADD statements? It's not like code between the CONTROL ADD statements which might get lost in shuffling the z-order.

[Adam J. Drake]

Keep your alterations outside the #PBFORMS statements and pbforms won't touch them...

[Chris Holbrook]

Keep your alterations outside the #PBFORMS statements and pbforms won't touch them...

you don't say... the point is, it is sometimes necessary to get between the DIALOG NEW and the CONTROL ADD statements, which PBFORMS groups together in one block.

[Adam J. Drake]

Sorry, running on very little sleep at the moment - misread the original post. At the moment, it simply doesn't support it (as you have found out).

That being said, what type of situation have you encountered that requires code alterations in between DIALOG NEW and CONTROL ADD? I haven't yet encountered a situation I couldn't workaround and keep it outside the blocks...

[Cliff Nichols]

Easy fix,

1. Create your dialog and controls in PB Forms
2. Copy/Paste the code to PbWin
3. Strip out the PBForms codes
4. Add your code where you want it
5. Compile
6. Run

[Chris Holbrook]

Easy fix...

I would call that a workaround, not a fix! In fact there is no problem compiling the code with both the #PBFORMS directives and my nonconforming line of code. It is in editing that the line is lost, not compiling.

It appears to me that PBForms assumes that there is no need to put code between the DIALOG NEW and the CONTROL ADD, and in assuming that it assumes too much.

[Steve Rossell]

Simply put your code outside of the #PBFORMS block statements and it will not be touched.

[Chris Holbrook]

what type of situation have you encountered that requires code alterations in between DIALOG NEW and CONTROL ADD?

setting a property of the dialog which is read by the control's WM_INITDIALOG.

[Chris Holbrook]

Simply put your code outside of the #PBFORMS block statements and it will not be touched.

There we go, speaking the same language and not communicating, again.

1. I know that PBForms won't touch code outside the #PBFORMS directives, because the documentation tells me so.

2. I take your comment to mean "there is no way you can change this behaviour", and that's OK too.

3. It seems pretty reasonable to me that someone might want to do something inside the dialog proc after creating the dialog and before the control's WM_INITDIALOG message is received. I've given you an instance of this. There are workarounds, both in procedure (re-edit the code after making design changes in PBForms, etc), and in technique ( use a global or send a WM_USER + message instead of using a property). But in either case, the design of PBForms is constraining either what the developer wants to do, or putting obstacles in his way in doing it.

4. It's not the end of the world, but I thought it worth bringing to the attention of my peers and the PBForms designer.

[Charles Dietz]

Chris, without knowing the details of your program, could you put off adding your controls until WM_INITDIALOG? I do that sometimes, anyway.

Edit: Sorry, I see how stupid this idea is... I don't use PBForms and I keep forgetting that it sets the rules for adding controls.

[Dave Biggs]

Chris,
Doesn't this work for you?

 
#PBFORMS BEGIN DIALOG %IDD_DIALOG1->->
...
#PBFORMS END DIALOG
 
 SetProp hDlg, "testProp", 1234
 
  DIALOG SHOW ...

[Chris Holbrook]

Doesn't this work for you?

Yes it does, and thank you Dave.

[Chris Holbrook]

could you put off adding your controls until WM_INITDIALOG?

Charles, the problem is to get info passed in to the callback proc, which takes no parameters. I don't want to use globals or a custom message, so using a property to pass a pointer to stuff seemed a good plan. Moving the ADD CONTROL statements to the callback works, but PBForms can't see them so it just shows you a blank dialog in the edit session.

In fact as I write Dave Biggs has identified the solution, and I was wrong about when WM_INITDIALOG is sent, I think WM_CREATE gets send right after the control is created but you don't see it until the ShowDialog starts messages beging sent to the callback proc, so I assume the WM_DIALOG is a DDT message. Anyway I was wrong about that and now its fixed.

I also hereby unreservedly withdraw my remarks re. design of PBForms before Mr Zales' lawyers come knocking.

[norbert doerre]

Yes, I also thought this to be repaired - I think about two years ago.
I wonder why nothing changed in the mean time.

[Rodney Hicks]

When I am working on any program that I used PBForms to design the layout on, which is almost all programs I work on lately, I keep the file in both PBForms and PB. By keeping the PBForms window open, but without focus, if I edit a line, anything, anywhere in the PB IDE, and Save it, compile it, run it, when PBForms subsequently gets focus, it prompts me to reload the file because it has been changed.
Conversely, changing something in PBForms means it has to be saved in order to pass the changes over to the PB IDE, although, now thinking about it I suppose CNTL-F7 might pass the changes as well.
I have never had a problem if I am just changing parameters in the code between Begin/End dialogs statements.
When adding new lines, if I really must, I place them between the End Dialog and Dialog show.

I took a break here and tried to add new lines in the Marked blocks and made sure that it was saved before returning to PBForms and sure enough, PBforms accepted the new line. I added lines in two marked blocks.

The only time I have problems is if I forget to Save/Compile/Run in the PB IDE, or Save in the PBForms IDE. Both prompth when a file is changed.

I do like to live with my cursor outside the Marked blocks though.
Rod

[Adam J. Drake]

Chris,

You could also make use of PostMessage to post a custom defined message (with parameters) to the message queue before DIALOG SHOW gets called. Not real sure what you're using for properties, but DIALOG SET USER works well and has space for 8 unique numbers.

[Chris Holbrook]

...I keep the file in both PBForms and PB.

me too

...PBforms accepted the new line.

Try putting stuff after the DIALOG NEW & before CONTROL ADD, and check the source using "View.DDT code".

[Chris Holbrook]

You could also make use of PostMessage to post a custom defined message (with parameters) to the message queue before DIALOG SHOW gets called.

yes but it's a workaround.

Not real sure what you're using for properties

see my recent posting in the source code forum

but DIALOG SET USER works well and has space for 8 unique numbers.

Well, there's something comforting about giving a name to a data item, as I said somewhere else, maybe I wrote too much COBOL. Windows properties would be OK if you could only see your own properties, but the way I read it is that to successfully remove your own properties when the dialog closes you have to know what they are called, which is not always the case.

[Michael Mattias]

the problem is to get info passed in to the callback proc, which takes no parameters. I don't want to use globals or a custom message

DIALOG NEW...

DIALOG SET USER  ....

CONTROL ADD....

[Dave Biggs]

(Chris breathes deeply, places palms together and utters the word "OM" while exhaling slowly)

DIALOG NEW... DIALOG SET USER.... CONTROL ADD....
Can cause problems when using PBFORMS
(But ..#PBFORMS END DIALOG... DIALOG SET USER.... DIALOG SHOW... Is OK)

I wonder if there could be a problem using Dialog Set User from a reusable code point of view - "Can I be sure that I haven't already used that user slot" - kind of thing?

SetProp / GetProp maybe looks better as you can use named data items.
(I suppose you could even use EnumProp to check if the name is already in use too).

I know that the docs say you must remove all entries your app has added to the windows property list before destroying the window but what problems could arise if you use EnumProps to remove all props before destroying it?