Thanks, all, for your responses!
Jay:
If only i had known this a week ago............ =)
This is exactly the information i was looking for when i said "I don't see
any clear reason or warning [why it won't work]."
Interesting thing, though, is that i was getting that error at runtime -
everything worked fine in the designers.
I don't have a problem with the design team's approach. Using the first
class defined in a file seems perfectly logical to me; i was just having a
hard time playing the game because i didn't know the rules!
Herfried:
didn't know one class per file was best practice - i'll use that approach
from now on. (Now all i need is some guidance in naming conventions since i
will have tons of class files all sitting right in the project root. Is
organizing your classes within project folders considered to be against best
practice?)
Thanks, guys!
---------------------------------
Now that the pleasantries are are out of the way, following is a bit more
discussion on what i *DO* have a problem with! =)
My complaint is with the high degree of indirection found in this (and many
other) error messages i see while working in VS.Net. If it wasn't for the
tiniest sprinkling of _my actual knowledge_ combined with a logical
troubleshooting approach, trial and error, patience, and LUCK, i would have
been totally stumped by this one, as well as a few others that have occurred
over the last few months i have been working on this project.*
This thing sent me on a wild goose chase looking for some
'frmDataEntry.resources' file that doesn't even exist! I tried locating the
file it said was 'missing' in the hopes that i might somehow be able to
're-connect' it to the assembly and hack this thing into working. (a total
waste of time) Checked my code for mistyped namespaces (as suggested by
M$ - another waste of time) Checked all my object's properties in the
designer ("Did i somehow accidentally activate some Localization
functionality? I must have, since that's what the error message pertains
to...") Then i tried deleting and re-creating 'frmDataEntry.resx', and
rebuilding the project & dependencies a bunch of different ways. Needless
to say, none of these approaches solved the issue. It's hardly surprising,
because as far as i understand it, the issue it was (falsely?) reporting had
no direct effect on why the program wasn't working...
Yes, i realize that the actual exception in the Framework's internal code
was probably something different altogether and that "Can't find the
resource file" is as close as .Localization could get to providing the user
with an exception message. Well........... i hope the .Net team can improve
on this state of affairs.
I would like to see more specific, properly-directed error messages in many
places in .Net. This is not the first time i have been sent into a confused
panic by something that "was just working" and then seemingly 'out of the
blue' starts throwing these errors which appear to be totally unrelated to
whatever changes i'm making.** In the particular instance we're discussing,
for example, i would expect an error something more to the effect of "VS.Net
IDE doesn't like multiple designable classes in the same source file. It's
causing something in Localization to totally choke when it tries to
instantiate this form at runtime."! (A new dialect: VB.Slang!)
to wrap this up in a succint metaphor: it's like if i had a car that was
out of gas, but when i asked it "Why won't you start?" it told me "The
battery is dead!!!" I realize that .Net is an incredibly complex 'car', but
still, it could at least narrow the error down to "fuel supply", instead of
trying to tell me ridiculous things like "The reason the car won't go is
because you left the trunk open!"***
-----------------
footnotes:
* - all the veterans are scratching their heads right now saying "What does
this guy think programming is all about, anyway?!" :P
** - now that i've been through 4 or 5 of these unnecessarily frustrating
elusive errors with misleading messages, in *my* mind, there is no such
thing as "totally unrelated" anymore... no matter what kind of improbable
cause the error message cites, i know to just "undo whatever i just did" and
hopefully things will work right again (cross fingers!). but it would still
be nice
*** - which reminds me of a (humorous) legendary leap in logic "cut off
fourth leg, frog goes deaf." :P
"Jay B. Harlow [MVP - Outlook]" <Ja********@email.msn.com> wrote in message
news:eL**************@TK2MSFTNGP09.phx.gbl...
For designable classes VS.NET has a restriction that the designable class
needs to be the first class in the file. In other words when the designer
opens the file it searches for the first Class and assumes that is the one
you want to design. This simplifies a number of things, as what happens
when there are two or more classes that inherit from Component, Form, or
UserControl in the same file. Should the designer open the first, the
second, the last or a random one in the middle? The approach the VS.NET
team took is to open the first.
As Herfried stated its best to have one class one file, especially when
those classes are designable, as this is effectively what VS.NET expects.
Hope this helps
Jay
"K. Shier" <ks*****@spamAtYourOwnRisk.yahoo.com> wrote in message
news:e2**************@TK2MSFTNGP10.phx.gbl... when i have the following code inside the .vb file that defines 'Public
MustInherit Class frmDataEntry', if i try to open a derived form based
on frmDataEntry, i get an error "Could not find any resources appropriate
for the specified culture...".
a little googling on this error made it simple to find the meaning, but
since it's one of those awesome situations where the error message bears NO MEANINGFUL RELATION WHATSOEVER to the error's actual cause, only trial
and error gave me the fix.
i don't see any clear reason or warning why 'Public Class
DataEntryFormOpenArgs' can't be defined in the same .vb file as
frmDataEntry (especially since frmDataEntry and forms derived from it are the classes
that will ever use DataEntryFormOpenArgs!) i haven't seen what happens
if i define the DataEntryFormOpenArgs at the bottom of the .vb file instead
of the top. maybe it would work - who knows. for now i just have it in a
.vb file of its own...
- Public Class DataEntryFormOpenArgs
- > Private _PKField As Object
- > Private _PKValue As Object
- > Private _sqlSelectCommand As String
- >
- > Public Property PKField() As Object
- > Get
- > Return _PKField
- > End Get
- > Set(ByVal Value As Object)
- > _PKField = Value
- > End Set
- > End Property
- >
- > Public Property PKValue() As Object
- > Get
- > Return _PKValue
- > End Get
- > Set(ByVal Value As Object)
- > _PKValue = Value
- > End Set
- > End Property
- >
- > Public Property SqlSelectCommand() As String
- > Get
- > Return _sqlSelectCommand
- > End Get
- > Set(ByVal Value As String)
- > _sqlSelectCommand = Value
- > End Set
- > End Property
- > End Class
now does that code really look like something that should be stumping
the Framework???
-------------
(*granted, it's only lunchtime, but i've got some free time on my hands
to write, so i'll publish this one, and if it gets superceded by something
even MORE annoying by the end of the day, then i'll owe you one!)
