[program-l] Re: windows forms in .net
- From: "David Lant" <david.lant@xxxxxxxxxxxx>
- To: <program-l@xxxxxxxxxxxxx>
- Date: Tue, 12 Dec 2006 12:16:35 -0000
Hi Justin,
Where you declare your form variables depends on what you want their
scope to be. If you know all your forms are going to have a lifetime
within that of frmMain, and you will always want to access the object
variables that instantiated them, then encapsulation might indicate that
you declare the form variables in frmMain. But if you wanted to be able
to instantiate a form variable in frmMain, but reference that variable
from another form, then you could declare it in a public or Friend
variable in a module. Since all the Windows applications I build here
have an MDI parent form, we declare and instantiate all our forms in
that, as the application itself has the same lifetime as the MDI form.
However, we only declare and instantiate them as and when they are
wanted, not as an up-front exercise as some applications do.
You have a few options for global data, depending on whether we're
talking about a desktop application or an enterprise, client/server type
one. For global data, you can create a module, and declare your global
variables in there as Friend or Public. That's the nearest you will get
to the old VB6 Global declaration. What kind of variable you use for
this is up to you. For example, in one system, I have a Friend
structure defined in the common module, which represents all the
identification and security permission information about the currently
logged on user. So when I want to know if a user has update permission
on a given part of the system, I can simply check CurrentUser.Update for
True or False. Alternatively, you could create a User class which is
instantiated at the logon screen, but whose variable is declared in the
main module, so that it can be accessed from anywhere in the project.
Another option is to serialise data to disk, and read it back in from
any class which needs to access it. That is clearly a bit of an
overhead, but makes sharing data between projects in a solution easier,
and sharing it between users on enterprise systems practical without
writing to a database.
One thing I would say is, be very sure that you really do want the data
to be global. AS you know, .NET and other object oriented development
systems tend to dissuade the use of global in memory variables. It
compromises stateless objects, and means you have to manage the global
data carefully. You might find that some circumstances aren't actually
global data, but simply parameters which need to be passed around from
object to object. That way, only the objects involved in the
transaction can see the data, rather than any object in the system.
Forms are often not global really, but simply need to be referenced
between specific instances of other forms for one reason or another. So
in those cases, you may just want to create a form property to hold a
reference to the desired form, rather than making it available to
everything, such as the CallingForm property I mentioned before.
So let scope and access guide you. If genuinely all form instances need
to be available from any part of the system, then make the variables
public in the project. But if that's not the case, just declare them in
the scope they are used, and pass references to them as parameters in
the occasions when it is needed.
David Lant
Senior Analyst/Programmer
Consultancy & Development
ICT Services
Devon County Council
Tel: (01392) 382464
Disclaimer:
http://www.devon.gov.uk/email.shtml
-----Original Message-----
From: program-l-bounce@xxxxxxxxxxxxx
[mailto:program-l-bounce@xxxxxxxxxxxxx] On Behalf Of Justin Daubenmire
Sent: 12 December 2006 11:54
To: program-l@xxxxxxxxxxxxx
Subject: [program-l] Re: windows forms in .net
Hi David,
thanks for the info.
when I call Application.start and pass it frmMain, when I go to show
different forms from frmMain, do I dim the new form from within frmMain
and
then show it? Or do I keep forms elsewhere like in a module?
In other words, will frmMain have all the form members that I can
enstantiate or do I keep them elsewhere like in a module?
Finally, what is a good way to keep global data available for all forms
in
the project. For example, once the user logs in, store the user name,
id,
phone, etc. in an employee object that all forms have access to.
How do you persist data between forms since this has changed since vb 6?
thanks.
Justin
----- Original Message -----
From: "David Lant" <david.lant@xxxxxxxxxxxx>
To: <program-l@xxxxxxxxxxxxx>
Sent: Tuesday, December 12, 2006 5:29 AM
Subject: [program-l] Re: windows forms in .net
> Hi Justin,
>
> As with most things, best practice depends on what the desired result
> is.
>
> Normally, you don't want to carry around anything in memory, or using
up
> resources, longer than is absolutely necessary. Tidying up behind you
> is a sadly dying art in the programming world. Anyway, if your
frmLogon
> screen is *never* going to be shown again during the life of your
> application, then best practice would be to lose it as soon as it is
> finished with. So in that case, unload it immediately after showing
> frmMain. On the other hand, if frmLogon might need to be displayed to
> request the user to enter more credentials, or log into another part
of
> the system, then hang on to it.
>
> One way to have the logon screen only be used at the start of the
> application, is to create a Sub Main in your Windows project, which
you
> set as your start-up object. In the sub main, you can show the
> frmLogon, and then only if that is successfully negotiated, start the
> system for real by using the Application.Run(frmMain) to kick off the
> rest of the system. If the logon fails, then just close the system
down
> after showing an appropriate message.
>
> The only time I hide a form, rather than unload it, is if I know the
> subsequent form is going to return to the one that called it. That
is,
> if I want the state of that form to be maintained while other forms
are
> being used. If I don't care what information is on the calling form,
> and don't care how the user gets back to it, then I tend to unload the
> form, and reload it again later when it is needed. In one system I am
> working on currently, we have an MDI parent form, which is always
> visible. A design decision was taken that all normal forms, i.e. not
> dialogs, that the user passes through would always be visible. It was
> decided that when a form opens another form, closing the child form
> would always return to the same instance of the parent form that
opened
> it. To achieve that, I added a CallingForm property to our standard
> inherited form class, so that every time a form is instantiated, it
can
> be explicitly told which form instance to return to when closed. This
> is because the Owner and MDIParent properties have more specific
> meaning, and couldn't be used for that purpose without damaging the
> normal behaviour of the forms.
>
> Remember that the JIT compiler will optimise code use, and the CLR
will
> manage code loading for you. So if you have a form which is
frequently
> used, but whose state is never maintained, then the CLR will use the
> library loaded into memory next time you load the form, rather than
> getting it from disk again. You can help this process by putting
forms
> which have a similar lifecycle into a common DLL. That way, as soon
as
> one form from that library is loaded into memory, the assembly for the
> others will also have been loaded, making it quicker to load them too.
>
> One thing I learned really early in my VB career, actually at James
> Corbett's VB4 course, was that you should always show the child form
> first, before unloading or hiding the parent form. This reduces
screen
> flicker on slower machines, and gives a thoroughly smoother
experience.
> How you manage the form in the background is up to you, depending on
> your application's requirements.
>
> So in summary, all your suggestions can be good practice. It just
> depends on what your criteria for success are. <smile>
>
> David Lant
>
> Senior Analyst/Programmer
> Consultancy & Development
> ICT Services
> Devon County Council
> Tel: (01392) 382464
>
> Disclaimer:
> http://www.devon.gov.uk/email.shtml
>
>
> -----Original Message-----
> From: program-l-bounce@xxxxxxxxxxxxx
> [mailto:program-l-bounce@xxxxxxxxxxxxx] On Behalf Of Justin Daubenmire
> Sent: 12 December 2006 10:11
> To: program-l@xxxxxxxxxxxxx
> Subject: [program-l] windows forms in .net
>
>
> Hi all,
>
> Using vs 2003 and vb.net and had a few questions on windows forms.
>
>
> I've read up quite a bit on this but wondering what is the best
> practise.
>
> if I have frmLogon and frmMain I want to unload frmLogon and show
> frmMain
> once the user supplies the correct criteria.
>
> For example:
>
> log on click
> dim frm as frmMain
>
> ' user passed criteria
>
> frmMain.Show()
> End Sub
>
> Some say to hide frmLogon and do not unload it.
>
> Some say to place frmMain outside of the sub in frmLogon and make it
> public
> to frmLogon.
>
> Some say to create a reference to frmMain and frmLog on in the
opposite
> forms via a member variable.
>
> Once at frmMain, this form will have around 15 forms that it will
have
> to
> show to the user and the user must interact with. What is the best way
> to
> show/hide forms in vb.net? You have to create an instance of each
form,
> understood, but what about showing/hiding forms? Is it that you
> show/hide it
> and never unload them from memory until the application exits?
>
> What is the best practise in this routine of things?
>
> thanks!
>
> Justin
>
> ** To leave the list, click on the immediately-following link:-
> ** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
> ** If this link doesn't work then send a message to:
> ** program-l-request@xxxxxxxxxxxxx
> ** and in the Subject line type
> ** unsubscribe
> ** For other list commands such as vacation mode, click on the
> ** immediately-following link:-
> ** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
> ** or send a message, to
> ** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
> ** To leave the list, click on the immediately-following link:-
> ** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
> ** If this link doesn't work then send a message to:
> ** program-l-request@xxxxxxxxxxxxx
> ** and in the Subject line type
> ** unsubscribe
> ** For other list commands such as vacation mode, click on the
> ** immediately-following link:-
> ** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
> ** or send a message, to
> ** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
** To leave the list, click on the immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** program-l-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to
** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
** To leave the list, click on the immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** program-l-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to
** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
Other related posts:
