> At some point, most of us will likely want to create an Employee web form
> (or similar) and an associated similarly named class.

> Well, if you create your web form Employee.aspx it will create a class named
> (by default) "Public Class Employee" underneath.  Now, if you then go to
> create a class (Employee.vb), it will do the same thing and you will have a
> conflict.

> What naming convention does Microsoft recommend to avoid this conflict?

> I certainly don't want to name my form EmployeeWindow or something {*filter*}
> like that.

> I have considered changing my underlying class names to frmEmployee and
> clsEmployee but Microsoft is now preaching against the use of Hungarian
> notation.

> > At some point, most of us will likely want to create an Employee web
form
> > (or similar) and an associated similarly named class.

> > Well, if you create your web form Employee.aspx it will create a class
named
> > (by default) "Public Class Employee" underneath.  Now, if you then go to
> > create a class (Employee.vb), it will do the same thing and you will
have a
> > conflict.

> > What naming convention does Microsoft recommend to avoid this conflict?

> > I certainly don't want to name my form EmployeeWindow or something {*filter*}
> > like that.

> > I have considered changing my underlying class names to frmEmployee and
> > clsEmployee but Microsoft is now preaching against the use of Hungarian
> > notation.

> That's all utter bullsh*t, don't listen to it. Just go and use the
> Hungarian notation.
> Sometimes they just have some really crappy ideas - other example: "We'll
> go back now to the time before Win 95 and start using ini files again,
only
> this time they'll be much more complicated because they're in Xml." Same
> bullsh*t here. Just ignore it if they have one of these really crapppy
> ideas again.

> --
> Tenchi (remove 'spam.be.gone' for emails)

> My VB.net Download-Manager (Version 1.12.1400)
> Homepage: http://www.*-*-*.com/
> Mailing list: http://www.*-*-*.com/

> Actually, I like the XML idea. Having your end-users edit the register was
> always a bit scary. They either would refuse to do it (a good stance on the
> issue IMO) or they would break their PC trying to do it.

> > Actually, I like the XML idea. Having your end-users edit the register
was
> > always a bit scary. They either would refuse to do it (a good stance on
the
> > issue IMO) or they would break their PC trying to do it.

> Well, one of the points of the registry is to keep Joe Average from
messing
> with the program's settings, so that the program can always work as it's
> supposed to.
> If your program requires your users to manually mess with the registry so
> that it can run properly, then something is *seriously* wrong with your
> program.

> --
> Tenchi (remove 'spam.be.gone' for emails)

> My VB.net Download-Manager (Version 1.12.1400)
> Homepage: http://home.arcor.de/minako.aino/DownloadWonder/
> Mailing list: http://de.groups.yahoo.com/group/dw-net/

> That is easy to say but in the real world, sometimes someone needs to edit
> the registry. Sure, it may be because of a bug in the software but that
> doesn't change anything. You still need to fix the entry so the customer is
> back up and running.