[program-l] Re: windows forms in .net
- From: "David Lant" <david.lant@xxxxxxxxxxxx>
- To: <program-l@xxxxxxxxxxxxx>
- Date: Tue, 12 Dec 2006 14:13:50 -0000
HI Justin,
Yes on both counts, with one slight modification. Smile>
Friend Structure CurrentUser
Friend Id As Integer
Friend NetworkName As String
Friend FullName As String
Friend Role As String
Friend Update As Boolean
End Structure
Friend is the same as Public, but restricts access to classes within the
same project.
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 13:15
To: program-l@xxxxxxxxxxxxx
Subject: [program-l] Re: windows forms in .net
Hi David,
thanks for the input.
You mentioned...
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.
so that would be like:
module
public oUser as User
end module
then in the log on form do...
oUser= new User(id, name)
is that correct?
Also you mentioned doing a friend structure in a moduel... did you do
something like this:
module
public friend structure
name as string
id as Integer
end structure
end module
thanks for any input.
Regards,
Justin
----- Original Message -----
From: "David Lant" <david.lant@xxxxxxxxxxxx>
To: <program-l@xxxxxxxxxxxxx>
Sent: Tuesday, December 12, 2006 7:16 AM
Subject: [program-l] Re: windows forms in .net
> 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
** 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:
