Re: one more somewhat dumb question... - C# Discussion Boards

Re: ShowDialog hides parent form

3-Feb-09 7:04

I think my best option is to repost this exact problem in a bout an hour, surely no one will remember it by then hahaha.... (Note to self; stop typing everything you think)

My opinion is... If someone has already posted an answer, dont post the SAME answer

musefan2-Apr-09 2:50

one more somewhat dumb question...

2-Apr-09 2:50

Answer seems to be that using this.Close() instead of this.Hide() seems to solve the issue.

i didnt use .Close() as i assumed that it would dispose of any properties i need to use but this does not appear to be the case

Life goes very fast. Tomorrow, today is already yesterday.

l a u r e n3-Feb-09 5:35

3-Feb-09 5:35

so i am writing a simple app to get the hang of .net and winforms... if i write some common functions as part of my "program" class how can i call them from a form? in mfc if was easy to get a ref to the app object and call from there but so far im not fining the equivalent here

any help appreciated
Smile | :)

"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"

musefan3-Feb-09 5:38

3-Feb-09 5:38

If i understand your question properly you can just use static functions, no?

My opinion is... If someone has already posted an answer, dont post the SAME answer

EliottA3-Feb-09 5:49

EliottA

3-Feb-09 5:49

I wasn't sure about his question either, is he trying to execute code from an event on a form or..?

musefan3-Feb-09 5:59

3-Feb-09 5:59

Not sure, from the question thou I gather its just calling a method within the Program class, which itself is a static class.

Personally if I have alot of common functions such as conversion algorithms or something, i just have a static 'Function' and call them whenever and whereever needed

My opinion is... If someone has already posted an answer, dont post the SAME answer

l a u r e n3-Feb-09 6:47

3-Feb-09 6:47

thats kinda what i'm doing and was wondering if thats "ok in .net" so to speak

"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"

musefan3-Feb-09 6:56

3-Feb-09 6:56

Yeah, I dont see why you shouldnt do it.

But as i said, prob best in another static class and leave the main Program class to do just what it needs, of course if you ever need login or splash screens, then you might be adding to the Program class

My opinion is... If someone has already posted an answer, dont post the SAME answer

l a u r e n3-Feb-09 7:20

3-Feb-09 7:20

sweet! thnx a lot
Smile | :)

"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"

Re: one more somewhat dumb question... [modified]

humayunlalzad3-Feb-09 5:57

humayunlalzad

3-Feb-09 5:57

Dont do any coding in the "Program" class for now.
The "Program" class has the Main method which in turn runs an instance of your Form.

Application.Run(new Form1());

The above line takes the control to the constuctor of Form1

public Form1()
    {
        InitializeComponent();

    }

So if you write any method you can run them here for a start

public Form1()
        {
            InitializeComponent();
            MyMethod()
        }

Luc Pattyn3-Feb-09 6:03

Luc Pattyn

3-Feb-09 6:03

Hi,

all methods are part of one class or other; there are no global methods.
A public static method is called by ClassName.MethodName(parms).
A public non-static method is called by MyClassInstance.MethodName(parms).

You normally pass MyClassInstance to whomever is interested, and/or you define an interface (which promises availability of some methods, but does not specify a particular class implementing them),
or, best of all, you pass a delegate (that is how you keep dependencies low).

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets

modified on Friday, June 10, 2011 11:39 AM

l a u r e n3-Feb-09 6:46

data connections and forms / apps

3-Feb-09 6:46

got it thnx ... i was still in web world (where i've been for too long it seems) where most member functions are public by default ... these were private by default so making them public worked
Smile | :)

"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"

l a u r e n3-Feb-09 4:58

3-Feb-09 4:58

so a question about general approaches...

in a desktop app (winforms say) is it better to open and close database connections with each form as it loads / unloads OR is it better to open a connection when the app starts and leave it open for the duration?

this is a low volume scenario with no more than 50 users expected simultaneously fyi

thnx
Smile | :)

"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"

Rob Philpott3-Feb-09 5:06

Rob Philpott

3-Feb-09 5:06

You could do either. I think the general approach is to create a connection each time because of something called Connection Pooling which is a cache of connections.

Either way, you want to seperate your DB calls from you GUI code - this is a good abstraction. Wrap up the DB access stuff in a Data Access Layer.

Regards,
Rob Philpott.

l a u r e n3-Feb-09 5:11

3-Feb-09 5:11

ok cool thnx ... when you say separate the db calls do you mean the open / close connection stuff or even further and use a whole class for the data calls for each form?

my approach would be to use stored procs / views and call them from the code ... is that not good?

thnx again

"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"

Rob Philpott3-Feb-09 5:30

Rob Philpott

3-Feb-09 5:30

Well, I'd be inclined to create a seperate project in your solution which provides class(es) which do the data access stuff. This project would reference System.Data, System.Data.SqlClient etc.

Your form code would reference this project and would not have any references to System.Data. This way, you seperate presentation from data acccess. This way if you change one data access function you only need to do it in one place and not in different forms etc.

The next 'step' would be to have some sort of client server architecture where the forms apps would talk to a server which in turn would forward the class on to the database, but this may be heavy-handed for what you want to do.

Regards,
Rob Philpott.

l a u r e n3-Feb-09 7:21

3-Feb-09 7:21

so a project is just a collection of classes?

"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"

Rob Philpott3-Feb-09 7:40

Rob Philpott

3-Feb-09 7:40

A project is a collection of classes, but it's also more than that. Typically in Visual Studio, a Solution is a collection of projects. Each project would normally be compiled into an assembly (which is a DLL).

It's normal to break up an application in this way. You might have your front end in its own project. Maybe you've got some custom controls, they'd be in another project (so that they could be reused elsewhere). You might have some business functionality in another project, and certainly data access would be another one. All these seperate projects comprise your solution.

When you build your solution, each project is compiled into its own assembly and they are all placed in the same folder. (This is private deployment if you want to look it up).

Projects obviously need to know about each other, and this is where references come in. If you right click on one in VS, there's an add reference option. Here you can reference your other projects and also system wide assemblies from the GAC.

Hope that makes some sense. Smile | :)

Regards,
Rob Philpott.

Le centriste3-Feb-09 5:21

Le centriste

3-Feb-09 5:21

As mentioned by Rob, there is a Connection Cache in ADO.NET. They are cached based on the connection string. So as long as you keep your connection strings the same, there is almost no overhead closing your connections and reopening them.

l a u r e n3-Feb-09 5:22

Re: changing button status

3-Feb-09 5:22

thnx

"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"

changing button status

R.Dubé3-Feb-09 4:48

R.Dubé

3-Feb-09 4:48

Hi all !

i'm trying to do something with one of my button. I got a logon form and i want to change de "visible" status tu true if the logon is accepted. The button is in the main form so i tried something like this :

<br />
if (str33 == encpassword)<br />
                            {<br />
                                PassTextBox.Clear();<br />
<br />
                                ChangeButton.Show();<br />
<br />
                                Main open = new Main();<br />
                                open.ChauffButton.Text = "dfg";<br />
                                <br />
                                <br />
                            }<br />

but it dosent worked. I jsut dont get it. Theres no error, nothing seem to be wrong but the status dont change. I even tried to change de text and got no result Confused | :confused:

Can someone help me on this please ?

BTW i'm using VS express 2008

Thanks !

l a u r e n3-Feb-09 5:00