I think you misunderstood me.
From your earlier posts, it appears that you you have a main form, and
somewhere before it's Load event handler finishes, you spawn a modal login
form and, in addition, the modal login form can be spawned on-demand.
It also appears that somewhere you have a method that does the configuration
of the menus depending on the value of the username.
What I was saying was this ...
In the main form:
Public Sub LoginOK(ByVal username As String)
'call the menu configuration method
End Sub
In the login form:
Private Sub OKButton_Click(...) Handles OKButton.Click
...
CType(Application.OpenForms("MainForm"), MainForm).LoginOK(username)
...
End Sub
This way you don't have to worry about what events are happening when or
keeping track of things with 'flags'. As I said earlier, this gives you
total control.
"Earl" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> The configuration part is done. Finding the appropriate event to fire the
> method was what I was looking for. I'm still testing it, but I'm getting
> the functioning I've been looking for. I ended up using the two static
> booleans and the MdiChildActivate event on the main form. That event fires
> BOTH when the MdiChild activates and when it deactivates. The easiest
> approach on the menus was to prepopulate with all selections and then use
> a switch to set the appropriate top-level menus visible or not.
>
> "Stephany Young" <noone@localhost> wrote in message
> news:(E-Mail Removed)...
>> Have you considered exposing a method in your 'main' form and calling
>> that method in the 'OK' button click event handler in the 'login' form.
>>
>> That way you will have total control over the configuration of the menu
>> items.
>>
>>
>> "Earl" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Jeff, thanks for the reply. That was actually one of my first attempts
>>> to solve the issue. The problem there is that the menus would fire when
>>> the form loads (it also activates). The menu setup boolean would be
>>> toggled and would not fire again on the login form OK click. So what I'm
>>> doing now is to set TWO static booleans from the login form, one for
>>> logged-in, and the other to say that a user has changed. Thus, on form
>>> activate, I check for logged in, if that is true, then check to see if
>>> the user variable has changed. If so, repopulate menus, if not, nothing
>>> happens. The only way both of those events could occur is if the user
>>> has clicked OK on the login form. I will probably take this one step
>>> further, confirm that a valid password has been entered, if not, give
>>> the user a small set of menu selections to change databases, log back
>>> in, or exit.
>>>
>>> Even more importantly, I've reconsidered the activated event. This will
>>> not trigger when closing an owned form.
>>>
>>> "Jeff Gaines" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> On 16/12/2006 in message <(E-Mail Removed)> Earl
>>>> wrote:
>>>>
>>>>>I want to populate the main menu strip based upon the user's status
>>>>>(i.e,. "user", "administrator", etc.) at time of login. The main form
>>>>>is running with the login form as an owned form, so I'd like to trigger
>>>>>this menu population at the time the user clicks OK on the login,
>>>>>closing the login form and returning focus to the main form. It appears
>>>>>that the best way to do this is when the main form gets re-activated,
>>>>>but obviously, the same event would trigger at the time any other forms
>>>>>return focus to the main form, so that doesn't seem very efficient to
>>>>>keep firing the menu population on form Activated. Any thoughts on a
>>>>>better way to do this?
>>>>
>>>> You could just set a boolean variable to false on loading the form and
>>>> true on activation - then bypass activation if it is true.
>>>>
>>>> --
>>>> Jeff Gaines
>>>> Damerham Hampshire UK
>>>
>>>
>>
>>
>
>
|
Similar Threads
