Showing and disposing forms [Resolved]

I'm starting an app from sub main. In the module there's a switchboard type form declared as public, that's is run in sub main. The switchboard the lets the user select record editing, which works as follows:
frmEntry is declared and shown from the click event of a button on the switchboard form. Here the user enters some parameters to select a record. When the user clicks ok, that event declares and shows the actual form (frmEdit) with the record data to be edited, and hides the Entry form.
But, when the user's done editing the record, there's no way to get back to frmEntry (from code, anyway) from frmEdit, because frmEntry's declared outside the scope of frmEntry.
Ok, so just declare all forms in the module, right? The problem there is that if the user closes frmEntry, then tries to reopen it, it's already been disposed of, and an error's thrown.
I could have a public sub in the module to declare forms, but I want to save the selected db (which is selected in a combobox), and the month, which is in a textbox.
Is there a way around this? Thanks.

Salve,

I don't know if this would be the appropraite way to handle your problem but...

I always pass my calling form into my target form, so I can "callback" a function in the original form when the secondary form does whatever it needs to do. I actually pass the form into the contructor, which allows me to overload the constructor and have different actions occur on the secondary form based on which form it was called from.


--Ben

Thanks, but the second form isn't recognizing the variable in the new constructor. It tells me "Name 'frm' is not declared". Maybe my code is wrong.
In the first form, call the second:

VB Code:

Dim frmRec As New frmRecEdit(Me)

In the second form, now two constructors:

VB Code:

Public Sub New()
        MyBase.New()
        'This call is required by the Windows Form Designer.
        InitializeComponent()    End Sub
 
    Public Sub New(ByRef frm As frmPrmpt)
        MyBase.New()
        InitializeComponent()
    End Sub

"frm" isn't recognized later in the second form.

Dear Friends, I have to premit that my english is very far to be perfect and I'm not sure to understand your problem in the right way. I have faced many times situations like yours in my applications and I probably could be useful to you, if I understood well. Ok....let's try! First question: Why don't You use a ShowDialog mode to launch the FrmEdit? There are others way to manipulate forms, I have used also very personal way to do it, but we have to start from the simplest way...and obviously there is a good reason because you can't use this obvious way, but I need to undestand why.

About to declare forms in a public module: It's not useful, if you then close them. You have to declare and instance a Form in a public module:

I Instance an object called FrmReg and another called FrmNota, from the classes: FrmRegistrazioni and FrmEditaPrimaNota (that are the forms I have designed) :

' ----------------- Dichiarazioni di Form -----------------------------------
Public FrmReg As New FrmRegistrazioni
Public FrmNota As New FrmEditaPrimaNota

The two objects will have to remain opened until your application is working (you can hide and show them, obviously) and they will be accessible from all others form.

Hope to be useful....
:)

Good job

Salve,

Here is a sample of my code. You need to declare a form variable outside of the scope of your constructor and use that. See here:

Code:

---

Public Class frmEditCustomer

    Private mfrmCaller As Form


#Region " Windows Form Designer generated code "

    Public Sub New()
        MyBase.New()

        'This call is required by the Windows Form Designer.
        InitializeComponent()

        'Add any initialization after the InitializeComponent() call
    End Sub

    Public Sub New(ByVal CallingForm As frmCustomerList)
        MyBase.New()

        'This call is required by the Windows Form Designer.
        InitializeComponent()

        'Add any initialization after the InitializeComponent() call
        mfrmCaller = CallingForm
    End Sub

---

Thanks alextyk, I understood your English well enough.
The problem with declaring them in a module is that if the user closes them, they can't re-open them because they've been disposed.
I suppose I could intercept the closing event and just hide them and reshow them, but that seems inefficient. I'd also have to check to make sure they're closed, data saved, etc., before closing the main switchboard form.
This was originally a standalone app that's being added to the switchboard. I may have to redesign the app to use just one form.

Wait....perhaps you want to say that the problem appears when user closes them? But user has only two ways to do it, I think:
1) Press (click) a button you placed in the form, and obviously you can control it.
2) With the default close button in the right-high corner with 'x'

You can keep off the default buttons setting the property ControlBox=False, but in this way you lose also the MinimizeButton, but is the easiest way.

I use another way. I intercept the closing event and cancel it (you don't need to reshow or reistance) if a particular flag is not set and then I set another flag that will run my procedure to exit, that checks for the values on the form, makes all it's needed to save and close everything.

For example:


Private Sub FrmEditaRiferimenti_Closing(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles MyBase.Closing
If Me.FlagEsciTranquillo = False Then
If Me.FlagBusy = False Then
Me.FlagBusy = True
Me.FlagEsci = True
End If
e.Cancel = True
End If
End Sub


You can simplify that:


Private Sub FrmEditaRiferimenti_Closing(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles MyBase.Closing
If Me.FlagEsciTranquillo = False Then
e.Cancel = True
End If
End Sub

And you can set Me.FlagEsciTranquillo = True, only after you have saved and checked everything. You can also give a message:

If Me.FlagEsciTranquillo = False Then
MsgBox("Before to exit you have to validate your input")
e.Cancel = True
End If

It tells to the user that a particular confirm button must be pressed

I hope I have given you some useful paths to follow:)

.....waiting for your eventual question :wave:

Thanks again. The saving and closing isn't the problem, though, it's that once closed the form can't be re-opened (without restarting the app). There's a module, a switchboard that calls the entry form, which calls the editing form.
The user edits one record at a time in the editing form. To select another record, the user returns to the entry form, which should retain two out of four selection criteria (db name and month). Then two other selection criteria are entered by the user, and they return to the editing form, and so on till they're done.
If the forms are declared in the module, the user can't open them a second time from the switchboard. If they're declared in the click event ( i.e., the switchboard click event declares the entry form), this problem is eliminated. But then the editing form has no way to call the entry form so the user can select a new record.
It was set up this way to mimic an existing Access system. The users can get confused by changes. :rolleyes:

BTW, your sig line in English is actually "Live long and prosper." :)

Salve,

Your app is structed just the same as mine.

In mine, the user looks at a customer list and double-click's which customer they want to edit. The Customer List form opens the Customer Edit form, and passes itself into the Customer Edit form. This way, when the user clicks 'Ok', I can call a function in the Customer List form to refresh the list and display any changes. For simplicity sake, lets call them the List form and the Edit form.



1) In your Edit form, a private variable declared as the type of your List form. It will be accessible to the Edit Form class, but that's all


2) In your New event declaration, accept a BYVAL parameter of the type of your List form.

3) In the code of your New event, set the local private variable equal to the one passed in.

You now have ahold of the List form in your Edit form class. You can call any public function of the List form at any point in time.

Does that help?

--Ben

Thanks. I ended up just making one form. It's kind of more intuitive that way anyway.
I probably could have used Ben's way; what I needed was a way for the edit form to reference the original entry form without declaring them in a module. If I run into this situation again, I'll try it out.

Dear Salvelinus, many thanks for your help. Poor Mr. spock! He's a victime of my bad translation! :bigyello:
I'm happy you have solved, anyway, your problem. Something is still hidden for my eyes, because it seems to me a tipical application for modal form, but, at this point, it's clear that I'm not understanding something (it should not be the first time!:rolleyes: )
Because I'm not sure if it can be useful to you, now, or in another situation, I try to expose a simple trick I have used....hoping to be able to explain in your language.....
I have a form named FrmStart.
From It I can direct my application in many ways.
It can show, declare and instance and close many other form.
It is a kind of Monitor in some way!
It's never closed and inside it, there is a timer.
Every 300 msec. the timer run a subroutine.
This sub routine can read and write and manipulate every forms where created at the level of form start.
A form, can ask to the frmstart to be closed, or to have an information read from another form, writing a special code in a public variable. FrmStart read all the form every 300 msec. and can act as they request to it. A form can ask to be hidden and to pass some value to next form to be showed. The cicling subroutines in FrmStart, read request and data from all forms and manipulate them following the logic you wrote in your code. I did this, but in many situations I found a more easy solution with an oculate use of modal form. Thanks again from starfleet :) :wave:

Isn't it great how programming problems can be resolved in so many different ways? That's what I love about this stuff...


ANyways, Alex, a great way to implement your idea is to use an MDI Parent form. It's got a built-in channel to all of it's children and offers alot of the functionality you're looking for.

Peace out all,

Ben

Dear Ben, at the moment I have no problem to solve about forms, but I've never used 'parent form'. I read something and I had the impression they could have a sort of preferred way to communicate with children, but what I read didn't solve my doubt. At the first time I'll need to implement something like discussed in this thread, I'll surely study the object. I'm in visual programming from less then a year.I have worked only in firmware, before, and I'm studying the new possibilities I have,here. But because of my habit to solve everything with a little amount of tools, sometime I start to face a problems with ridicolous instruments. Until now, I've always solved them, but often in a very 'personal' way.:D
It's really fascinating, dear Ben, the lot of opportunity we have to create our own solution. It' s a very creative activity. I'm surprised that many people consider a technical job something aseptic and bouring. Happy to met you, dear friends.:)