Re: How to pass information, classes between forms in Windows Application mode
- From: raylopez99 <raylopez99@xxxxxxxxx>
- Date: Wed, 23 Jul 2008 12:06:40 -0700 (PDT)
On Jul 23, 11:17 am, Jon Skeet [C# MVP] <sk...@xxxxxxxxx> wrote:
raylopez99 <raylope...@xxxxxxxxx> wrote:
<snip>
OK, see below for an example, but keep in mind your console mode
example fails to be instructive for several reasons: (1) it's console
mode not Forms. Totally different, and if you don't see it that way no
use further discussing this issue.
In that case I guess it's the end of the discussion.
That's right. You haven't been as helpful as before, I suspect because
you don't like to reply to me, and also because you don't understand
the newbie concerns I had. I particular, as per my last post, I
pointed out why these errors occurred, and how to correct them
(reproduced below) But you refuse to comment because I suspect you
feel this is beneath you (assuming, charitably, you even are aware of
these problems--it's quite possible that because your coding style is
different and you deal with console mode, you never even come across
this problem, and perhaps you're not even aware of this problem)..
Forms apps are certainly more *complicated* than Console apps, because
there's all the designer code involved, and basically a lot more
*stuff*. But the language itself doesn't change.
Nobody said the language changed--those are your words. The issue is
'entry points' and you surprised me by even acknowledging you know
what this term means, since it's kind of obscure. I expected you would
say 'define entry point'.
Please show who you could possibly have the Main method *not* in a
class or struct.
Not the issue. The issue is having Main inside a class, as is often
done with console examples (I like the old style--main being outside
with the classes inside it--do you even know what that old style is?
LOL).
It goes to the heart of why form Form2:Form1 cannot
'see' Class0 unless Class0 is declared public *twice*, not just nested
with keyword public, but in the declaration public Class0 myClass0;
before the class Class0 is defined.
That's not declaring a class. That's declaring a variable called
myClass0, of *type* Class0. The sooner you understand that, the better.
Unless you use the "class" keyword, you're *not* declaring a class.
OK, fine. FYI you might want to examine the sample code I provide
below, and convince yourself it will not work properly unless the
conventions I clearly outline below are followed. Then, in your own
words, point out why you think so--feel free to use all the fancy two-
bit words you can think of.
No, but I said what you needed to do for me to answer it: post a short
but complete program. When you do that, I'll answer your question.
But what question are you looking for? I've outlined the scenario
below. Study it and convince yourself. If you need a complete
example to understand what is happening below, you are a poor
programmer for sure. And you wrote a book? What was it, self
published?
I understand everything that occurs in the C# language in this thread.
I don't understand some of what you're trying to communicate because
you persist in talking inaccurate terms (such as "forward references")
and posting incomplete programs.
Oh, I see. You claim to "understand everything" yet you fail to tell
us what you understand, and give the impression of being a troll and
newbie. I will be charitable and assume you're just yanking my chain
and don't expect to ever answer any question or make any comment,
other than harp about proper terminology. But to be unkind I could
suspect you don't know what you're talking about. In the future, I'll
have to examine what you say more closely, as it might be completely
wrong. Perhaps you're not the expert I assumed you were, if you don't
even understand and cannot comment on the below program.
If you'd post a complete program which either you believe goes against
something I've said,
What did you say? Nothing of much importance, except be sure to use
the right words when describing a problem. But this assumes you even
recognize a problem exists, which in this thread you have not.
RL
Study and commit to memory, I've added a few Easter Egg comments
tailored just for you Jon:
Here it is:
////////// START OF PARTIAL CLASS FORM1: Form
public partial class Form1 : Form
{
Class1 myClass1; //cannot comment out this line--compile error
<--do you know why, Jon?
Class2 mYClass2;
public Form1()
{
InitializeComponent();
// Class1 myClass1 = new Class1(100,
"heLlO1YouTube!"); //
HIDES or 'overrides' previous declaration! <--Jon, does this ring a
bell? Have you done this? If not, why not? Coding style perhaps?
//if you pass class as above rather than below line, you
get null pointer! -wrong!! <--Jon, do you understand why this is *not*
a null pointer, but a null reference, and why most people think that's
bad, regardless of what you call it?
//instead, use this...
myClass1 = new Class1(100, "heLlO1YouTube!");
mYClass2 = new Class2(69, "hello2FooTUbE!");
}
private void clikMeNewFToolStripMenuItem_Click(object sender,
EventArgs e) //<--Jon, are you confused as to what
"clikMeNewFToolStripMenuItem_Click" method does, and do you understand
why it's not important? "But give me complete code!" says Jon,
unaware that in Forms some of the complete code can run a few thousand
lines for even a simple windows application!
{
Form2 frm2 = new Form2(myClass1, mYClass2); //<--do you
know, reading this thread, why we are using parametric constructors
rather than default parameterless constructors?
frm2.Show();
}
////////// END OF PARTIAL CLASS FORM1 : Form
// start of Partial Class Form 2: Form
namespace MDIForms
{
public partial class Form2 : Form
{
Class2 myClass2;
Class1 myNewClass1;
public Form2() //default constructor not used
{
InitializeComponent();
myClass2 = new Class2();
myNewClass1 = new Class1(99, "new!Class1!!");
}
public Form2(Class1 passClass1, Class2 passClass2)
{
myClass2 = passClass2;
myNewClass1 = passClass1;
}
// end of Partial Class Form 2: Form
Discussion: classes 1,2 are simple classes, that contain a public
int
and public string as members, declared OUTSIDE the Form1 class, and
are not nested to the Form1 class, nor is Form 2 inherited from
Form1, but the important point is that in C# there is 'hiding' of
previously declared classes. This is illustrated by the line //
Class1 myClass1 = new Class1(100, "heLlO1YouTube!"); //HIDES or
'overrides' previous declaration!
{Jon would argue this is imprecise terminology: it's "declaring a
variable called myClass0, of *type* Class0.", and would then point out
that "hiding" is an imprecise word to use, since you are declaring and
defining and instantiating a new local variable that has the same name
as the variable "myClass0". I think. But he would not understand
this until AFTER I had figured out an answer to my own question,
largely because Jon either, because of convention, never makes these
kind of newbie mistakes (he follows a template that has shielded him
from these mistakes, codes largely in Main where such mistakes are
easier to spot, or, charitably, he is just being an ass in this
thread. I think perhaps it's the last reason but maybe it's the
former--does Jon Skeet know what he's talking about? I'll have to
check his posts more carefully in the future.}
Even though myClass1 is declared outside the default constructor of
Form1, it is 'overridden' (I am using imprecise terminology, but if
you're astute you will understand the problem) by the second
declaration of myClass1 inside the default constructor of Form 1.
And, using this 'wrong' way, you will get a null reference passed to
Form2, which is not correct.
And, commenting out the line "Class1 myClass1; //cannot comment out
this line--compile error" is even worse--you will get a compile error
rather than a runtime error, since myClass1 inside the normal default
constructor of Form1 will be treated as a local variable that cannot
be seen elsewhere.
If you understand this simple example you're half way towards
understanding the problem in this thread. {assuming you even care
about understanding the problem rather than pushing your own agenda}
.
- Follow-Ups:
- Re: How to pass information, classes between forms in Windows Application mode
- From: Jon Skeet [C# MVP]
- Re: How to pass information, classes between forms in Windows Application mode
- References:
- How to pass information, classes between forms in Windows Application mode
- From: raylopez99
- Re: How to pass information, classes between forms in Windows Application mode
- From: Jon Skeet [C# MVP]
- Re: How to pass information, classes between forms in Windows Application mode
- From: raylopez99
- Re: How to pass information, classes between forms in Windows Application mode
- From: Jon Skeet [C# MVP]
- Re: How to pass information, classes between forms in Windows Application mode
- From: raylopez99
- Re: How to pass information, classes between forms in Windows Application mode
- From: Jon Skeet [C# MVP]
- Re: How to pass information, classes between forms in Windows Application mode
- From: raylopez99
- Re: How to pass information, classes between forms in Windows Application mode
- From: Jon Skeet [C# MVP]
- Re: How to pass information, classes between forms in Windows Application mode
- From: raylopez99
- Re: How to pass information, classes between forms in Windows Application mode
- From: Jon Skeet [C# MVP]
- How to pass information, classes between forms in Windows Application mode
- Prev by Date: Re: making this C# procedural function an OOP function - get rid of the parameters
- Next by Date: Re: Next available drive letter - mpr.dll
- Previous by thread: Re: How to pass information, classes between forms in Windows Application mode
- Next by thread: Re: How to pass information, classes between forms in Windows Application mode
- Index(es):
Relevant Pages
|
Loading