I must be missing something here, but when using the Localization and Messaging Editor, how do I search for a value or key? In Visual Studio in the Forms Designer, it's possible to right-click on a control and get the search key or value functionality. Where is this in the actual Localization Editor?



Thanks,

Derek

Ohhh...tab after new...nice Yeah that makes it way more palatable. Thanks for the tip!

Yeah...and it will ALWAYS bring up the right object and include any required namespacing, etc. Me likey!

A year ago when I was getting into .NET I knew I should go with VB.NET since coming from a VFP environment the majority suggested VB.NET instead of C#, so far I love the whole .NET and specially when comparing the VS IDE with the VFP IDE I am more than happy I made the jump, still I am getting to know VB and will wait for a new small project to start working on C#, also I want to see all the new improvement to both languages coming in the new VS2010 before getting too deep .



Thanks both for sharing those experiences.

Edhy Rijo

I have to say I'm happy that I started with VB. Keeping the language sort of close limited what I was learning, which was a ton. There was all the OOP features, the .NET framework and the SF framework.



Now that I'm much more comfy with .NET OOP, and the frameworks, the jump to C# has been pretty easy. Now, when I go back to vb, there seem to be a lot of extra semi-colons!



The latest thing I'm not liking about C# (though I mostly like it better now) is the switch statement. This is somewhat analogous to the select/case statement but it is more limited. Here is something I do often in VB that is not possible in C#:







This is not possible in C#. The case elements must be resolvable at compile time. Thus they can use variables of strings of primitive types, strings or other primitive types. Oh well.

Unless you are dynamically changing the panel names, then this is totally possible. You would just entry it as a string:

Well, I'm not dynamically changing the panel names, I just really hate things like this as constants. So what you suggest is exactly what I was attempting to avoid. What does happen a lot during development is that I might change the name of the control (in this case the panel page) and in VB the automatic refactoring just handles it (the case statement is updated). With this (string contants) I'd have to remember to go fix it. Likely I wouldn't remember and I'd have to track down the bug. Hopefully they'll update this soon in C# (as they've stated that VB and C# will be equivalent languages, with features being introduced in both at the same time...not sure it applies to this but a guy can hope). Oh well. At this point I mostly prefer to work in C#, but I'm more convinced now that which language you choose is really just a preference (except for the stupid compile all the time thing with vb). Thanks for the info.

Well, when you are in the middle of development and changing names, OK. But if you go back in after this is working and start changing names then that is like playing Russian Roulette. The very same argument could be made for any single piece of code that has a string key, dictionary, etc. So while you may refactor your code while developing it you would also still recall this needs to be modified. But if you are changing "keys" after this code is already working, then you obviously would have a good reason, but this really should be a moot point. But that is just my point of view.