Modal form load

[DickDavies]

I have a modal form consisting of a rich text box and two command buttons (save and exit) which can be called from other forms (mdichild) in the app.

calling code:
If FormEdit.Visible Then Unload FormEdit
FormEdit.Show 1

When loaded the command buttons on the modal form ignore the first few clicks ! If I set a breakpoint on the 'FormEdit.Show 1' command then all is ok !!

The modal form seems to recursively fire events load/activate/queryunload/unload each time a command button is clicked - but after a few clicks all is ok.

I use some global variables in the modal form - is it possible that it loads too fast ?

 

[TGandon]

When your reaches

If FormEdit.Visible Then Unload FormEdit

If FormEdit is not loaded then "If FormEdit.Visible" will load the form firing the load and activate events.
This is then followed by "Unload FormEdit" which fires the queryunload and unload events.
All before you get to FormEdit.Show.

As I understand it, using a modal form halts the code in the calling procedure until the form is unloaded or hidden
e.g.

If ConditionIsMet Then
   FormEdit.Show vbModal
   'Code execution in this procedure will continue here when FormEdit is hidden/closed

   'Whatever code goes here
End If

Trevor

 

[BobRodes]

Rather than checking the Visible property of the form, which creates weird behavior for the reasons that Trevor explains, check the Forms collection to see if the form is loaded. However, I'm not sure I understand why you are doing this in the first place. Perhaps you'd care to explain further?

Bob

 

[TGandon]

I agree with Bob about using the Forms collection.

I guess the point I was trying to make was that if FormEdit is only ever used modally then the

If FrmEdit.Visible Then Unload FormEdit

is irrelevant because the only time it is visible is when you show it.
i.e. code execution in the calling procedure halts until FromEdit is hidden or unloaded so, FromEdit must be hidden or not loaded when code execution resumes.

Trevor

P.S. I find the code easier to read if VB's inbuilt constants are used as in

FormEdit.Show vbModal

 

[mattKnight]

Whilst all the above suggestions will solve your immediate problem, I'd suggest that you think about using a form reference variable.

Example

dim f as FormEdit

Set f= New FormEdit

f.Show vbModal

using FormEdit directly as I suspect you are can lead to odd problems with the lifetime of the form.



Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[DickDavies]

Thanks for your responses.

To try and track down the problem I created a different form (formB) with only 1 command button (unload me).

When called modally from the calling form FormA (from a RichText_Click event)

Dim FormM As New FormB
FormM.Show vbModal

Clicking the unload command on formM does not unload it but creates another instance.
If I put a break point on the .show command in FormA then FormM unloads correctly.
I have various mousemove and mouseover events in FormA - could any other event retrigger the click event or am I just going mad ?

I use vb6.0 (SP6). I have segregated the edit routines into their own form because the calling forms are quite big and I still use W98 at home and have reached the 64k limit.

Dick D

 

[strongm]

Actually, it looks to me like you may have discovered a bug in the RichTextbox's Click event.

 

[BobRodes]

I haven't been able to duplicate the behavior. Does the problem only exist in compiled mode?

 

[strongm]

Unable to duplicate? Really? Two forms. Drop a richtextbox onto form1, then add this code:

Private Sub RichTextBox1_Click()
Dim FormM As New Form2
FormM.Show vbModal
End Sub

Run the program, click on the richtextbox. A nice shiny new Form2 appears. Now click anywhere you like ...

(VB6 SP6 XP SP1 and SP2)

 

[BobRodes]

<Unable to duplicate? Really? [etc.]

Note for metatags:
[brit] Responses in British. Please understand that British is a second language for the writer.
[amer] Responses in American.
Language not contained in either should be mutually intelligible.

[brit]
strongm, though with your unusually acute capabilities you may be able to show otherwise, my own not inconsiderable experience reveals that the three lines of code that I used are substantively identical to the three lines of code that both you and Mr Davies used. That given, it follows that I did indeed correctly, and upon first attempt, grasp, not to mention implement and test, the concept that both Mr Davies' and your clarifying post were attempting to convey. Permit me therefore (with all necessary apologies for being annoying and inconvenient) to repeat that my results indeed vary from the results described, and add that they appear to do so for reasons other than my lack of understanding of the concept put forth.

Now, strongm, you will of course make free to point out any difference the light of your superior capabilities may reveal between the three lines of code herein set forth and the three lines of code that you provide, that would in and of itself account for the variance in behavior. Of course, if you do indeed find such a difference, one must observe that such a finding would constitute a workaround to the difficulty at hand, upon which one has stumbled, albeit inadvertently, and one will accept in advance your thanks.
[/brit]

[amer]
Daggone, strongm, I think I know how to write 3 trivial lines of code without screwing it up! Here's the code I wrote ahead of your post, without any help from you. And get this: my shiny new Form2 does indeed unload, or at least disappear from any context available to the VB development environment, and furthermore, no new instances of the form are created. Now, if you find something "wrong" with my code, I'd say I've fixed the version you provided, since mine works and yours doesn't, and I guess you can thank me for it.
[/amer]

[brit]Right. We've had our little diversion, one will assume not at strongm's expense, so let us now focus on the topic in question.[/brit][amer]All right, that was all kinds of fun, and I figure strongm's skin is thick enough that his nose hasn't gotten out of joint. Now let's get down to business.[/amer] Here's the code I used.

Form1:

Private Sub RichTextBox1_Click()
Dim cForm As New Form2
cForm.Show vbModal
End Sub

Form2:

Private Sub Command1_Click()
Unload Me
End Sub

strongm, taking your "click anywhere you like" directive literally yields the following data on my machine:
1. Clicking on form2's command button closes the form. Clicking again on the rich text box opens it again. Clicking anywhere else on form2 (with the exception of the controls in the top right corner, which behave as expected) has no effect. Behavior repeatable.
2. Clicking anywhere on form1 causes the title bar on form2 to flicker 3 times, as if it were being made the current form and then not the current form, and then the current form. (Not having sound capability on my current machine, I can't say if the bell rings or not.)
3. Clicking the rtb, closing the modal form, and repeating the process causes the form's position to change on the screen, in the manner of overlapping MDI child forms. This was the most interesting thing I found, so I bolded it. Perhaps phantom instances are running around?

Conclusion: although the behavior is buggy, I'm unable to duplicate the described behavior.

If I can provide further information or do more arcane tests on my platform at your direction, please advise.

For the record, I get the same behavior with no SP and with SP6.

Bob

 

[strongm]

Sorry - but given that DickDavies only mentioned that the call was being made from a RichTextbox click event in brackets, and given thread222-1112494 where one line of code made a significant difference I thought it best to check ... ;-)

>causes the title bar on form2 to flicker 3 times
>causes the form's position to change on the screen, in the manner of overlapping MDI child forms

Sadly, both of these are pretty standard behaviour

>Clicking on form2's command button

The command button seems to be an irrelevance (which is why I left it out of my code). If you've got the buggy behaviour (which you have not but DickDavies and myself do) it is the simple act of clicking on any screen real estate belonging to the application that causes a new instance of the second form to pop up

 

[BobRodes]

<thread222-1112494
You would bring that up. LOL All right, fair enough.

I've been guilty of a couple of careless responses lately. I could have saved a lot of time in thread708-1112390 if I had read the code more carefully at the outset, although in this case, fortunately, it didn't seem to matter.

So, I will be more careful in future, and apologies to anyone I've inconvenienced.

As for this thread, I wonder if having the New keyword on the declaration line has anything to do with it (something having to do with the instance checking algorithm)? I also wonder if just showing the form, without having a reference variable, still does the same thing (ergo, nothing to do with VB variables)? Probably not, in both cases. If so, why would they work on my machine? BTW, I'm using a Win2000 Professional OS.

Bob

 

[strongm]

Trying it without the New keyword was one of the first things I tried. What I then get , instead of a new Form2 opening when clicking anywhere, is runtime error 400 (Form already displayed; can't show modally)

Win2000, eh? Well, as I said earlier I'm on XP. I wonder what the original poster is on, as it could well be OS dependant

 

[DickDavies]

Hi guys,

Thanks again for your efforts.
For info. I have been testing on XP SP2. I have tried all manner of calling this modal form, setting flags, calling via the MDIForm etc. etc. - the return always retriggers the calling line (and ignores my flags).

I've chickened out and changed the modal form to standard (non modal mdichild), in it's load event I disable the calling form and reenable it on unload - works ok !!

Dick D

 

[BobRodes]

Smells like an xp problem. Maybe the little doggie's to blame....

 

[strongm]

Well, I suspect that it is probably related to the richedit control that ships with the OS and that underlies VB's RichTextBox control.

Bob, Dick, can you check the version of RichEd20.dll you have installed (this is actually richedit version 3.0, which contains an emulator for richedit version 1, which is required for the VB richtextbox)?. My version is: 5.30.23.1211

 

[strongm]

Oh, and also the version of RichEd32.dll (which is the stub/wrapper for richedit 1.0). My version is: 5.1.2600.0

 

[gmmastros]

I've attempted to duplicate the problem also.

On my laptop at home, it works that way you expect it to.
On my computer at the office, it exhibits the buggy behavior.

Office Computer:
RichEd20.dll Version 5.30.23.1221
RichEd32.dll Version 5.1.2600.0
RichTx32.ocx Version 6.1.97.82

Laptop:
RichEd20.dll Version 5.30.23.1221
RichEd32.dll Version 5.1.2600.0
RichTx32.ocx Version 6.0.81.69

To reiterate, laptop not buggy, office computer buggy.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[strongm]

Which OS, George?

Oh, and my OCX version (which I didn't think was going to be relevant, but may turn out to be) is: 6.1.97.82

 

[gmmastros]

both os's are Windows XP professional.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom