By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,280 Members | 1,232 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,280 IT Pros & Developers. It's quick & easy.

Annoying Micro$oftian Kludge Of The Day*

P: n/a
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...

Expand|Select|Wrap|Line Numbers
  1. Public Class DataEntryFormOpenArgs
  2. Private _PKField As Object
  3. Private _PKValue As Object
  4. Private _sqlSelectCommand As String
  5.  
  6. Public Property PKField() As Object
  7. Get
  8. Return _PKField
  9. End Get
  10. Set(ByVal Value As Object)
  11. _PKField = Value
  12. End Set
  13. End Property
  14.  
  15. Public Property PKValue() As Object
  16. Get
  17. Return _PKValue
  18. End Get
  19. Set(ByVal Value As Object)
  20. _PKValue = Value
  21. End Set
  22. End Property
  23.  
  24. Public Property SqlSelectCommand() As String
  25. Get
  26. Return _sqlSelectCommand
  27. End Get
  28. Set(ByVal Value As String)
  29. _sqlSelectCommand = Value
  30. End Set
  31. End Property
  32. 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!)
Nov 20 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Hi K,

Have you tried nesting your DataEntryFormOpenArgs <within> your base
class? If it's truly only for that and derived classes, then it will work
logically. Maybe it will rid you of your error too?

Regards,
Fergus
Nov 20 '05 #2

P: n/a
Hello,

"Fergus Cooney" <fi******@tesco.net> schrieb:
Have you tried nesting your DataEntryFormOpenArgs
<within> your base class? If it's truly only for that and
derived classes, then it will work logically. Maybe it
will rid you of your error too?


Are you sure this is best practice?

--
Herfried K. Wagner
MVP VB Classic, VB.NET
http://www.mvps.org/dotnet

Nov 20 '05 #3

P: n/a
Hello,

"K. Shier" <ks*****@spamAtYourOwnRisk.yahoo.com> schrieb:
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...".
I am not able to compile a project that includes a form marked as
'MustInherit' (VS.NET 2002), but I get a different error.
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...


Each class whould be placed in its own source file (except nested classes
;-).

--
Herfried K. Wagner
MVP VB Classic, VB.NET
http://www.mvps.org/dotnet
Nov 20 '05 #4

P: n/a
K. Shier,
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... 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...

Expand|Select|Wrap|Line Numbers
  1. Public Class DataEntryFormOpenArgs
  2.      Private _PKField As Object
  3.      Private _PKValue As Object
  4.      Private _sqlSelectCommand As String
  5.      Public Property PKField() As Object
  6.          Get
  7.              Return _PKField
  8.          End Get
  9.          Set(ByVal Value As Object)
  10.              _PKField = Value
  11.          End Set
  12.      End Property
  13.      Public Property PKValue() As Object
  14.          Get
  15.              Return _PKValue
  16.          End Get
  17.          Set(ByVal Value As Object)
  18.              _PKValue = Value
  19.          End Set
  20.      End Property
  21.      Public Property SqlSelectCommand() As String
  22.          Get
  23.              Return _sqlSelectCommand
  24.          End Get
  25.          Set(ByVal Value As String)
  26.              _sqlSelectCommand = Value
  27.          End Set
  28.      End Property
  29.  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!)

Nov 20 '05 #5

P: n/a
Hi Herfried,

'Best' is a fuzzy word*. But the DataEntryFormOpenArgs are a helper class,
and presumably invalid outside. So why not?

Especially if it makes the error go away. :-)

Regards,
Fergus

* Especially if it's George Best :-)
Nov 20 '05 #6

P: n/a
there is another similar situation where i did it the way Fergus suggested
and it seems to work.

Whether it is best practice or not, though, i don't know...

if Herfried is doubtful, chances are the answer is 'No'! =)

"Herfried K. Wagner [MVP]" <hi*******@m.activevb.de> wrote in message
news:ex**************@tk2msftngp13.phx.gbl...
Hello,

"Fergus Cooney" <fi******@tesco.net> schrieb:
Have you tried nesting your DataEntryFormOpenArgs
<within> your base class? If it's truly only for that and
derived classes, then it will work logically. Maybe it
will rid you of your error too?


Are you sure this is best practice?

--
Herfried K. Wagner
MVP VB Classic, VB.NET
http://www.mvps.org/dotnet

Nov 20 '05 #7

P: n/a
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...

Expand|Select|Wrap|Line Numbers
  1. Public Class DataEntryFormOpenArgs
  2.  >     Private _PKField As Object
  3.  >     Private _PKValue As Object
  4.  >     Private _sqlSelectCommand As String
  5.  >
  6.  >     Public Property PKField() As Object
  7.  >         Get
  8.  >             Return _PKField
  9.  >         End Get
  10.  >         Set(ByVal Value As Object)
  11.  >             _PKField = Value
  12.  >         End Set
  13.  >     End Property
  14.  >
  15.  >     Public Property PKValue() As Object
  16.  >         Get
  17.  >             Return _PKValue
  18.  >         End Get
  19.  >         Set(ByVal Value As Object)
  20.  >             _PKValue = Value
  21.  >         End Set
  22.  >     End Property
  23.  >
  24.  >     Public Property SqlSelectCommand() As String
  25.  >         Get
  26.  >             Return _sqlSelectCommand
  27.  >         End Get
  28.  >         Set(ByVal Value As String)
  29.  >             _sqlSelectCommand = Value
  30.  >         End Set
  31.  >     End Property
  32.  > 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!)


Nov 20 '05 #8

P: n/a
Hello,

"K. Shier" <ks*****@spamAtYourOwnRisk.yahoo.com> schrieb:
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?)


Don't use naming conventions that cause ugly class names. You can group the
classes in a folder tree.

--
Herfried K. Wagner
MVP VB Classic, VB.NET
http://www.mvps.org/dotnet
Nov 20 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.