StrataFrame Forum » StrataFrame Database Deployment Toolkit » Database Deployment Toolkit (How do I?) » Localization and Messaging Editor Search

Localization and Messaging Editor Search

Derek Price — Mon, 24 Aug 2009 13:50:01 GMT

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

RE: Localization and Messaging Editor Search

Trent L. Taylor — Mon, 24 Aug 2009 13:50:01 GMT

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. :)

RE: Localization and Messaging Editor Search

Greg McGuffey — Mon, 24 Aug 2009 12:09:35 GMT

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.

RE: Localization and Messaging Editor Search

Trent L. Taylor — Mon, 24 Aug 2009 09:25:38 GMT

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

[codesnippet]switch(panelName)
{
case "Panel1":
{
}break;
case "Panel2":
{
}break;

}[/codesnippet]

RE: Localization and Messaging Editor Search

Greg McGuffey — Thu, 20 Aug 2009 13:55:04 GMT

[quote][b]Edhy Rijo (07/08/2009)[/b][hr]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 :hehe:.[/quote]

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! :blink:

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#:

[codesnippet]Select Case Me.PanelManager1.CurrentPage.Name
Case Me.PanelManagerPage1.Name
Case Me.PanelManagerPage2.Name
End Select[/codesnippet]

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.

RE: Localization and Messaging Editor Search

Trent L. Taylor — Wed, 29 Jul 2009 09:36:28 GMT

Download the 1.7 build, it is in there. ;)

RE: Localization and Messaging Editor Search

Derek Price — Tue, 28 Jul 2009 07:55:45 GMT

Edit: I just realized that I posted this in the wrong place!:hehe:

Well, another month has gone by and I was curious how the progress on the new Localization Tool/beta release is coming.

Thanks,
Derek

RE: Localization and Messaging Editor Search

Derek Price — Mon, 27 Jul 2009 12:17:26 GMT

Well, another month has gone by and I was curious how the progress on the new Localization Tool/beta release is coming.

Thanks,
Derek

RE: Localization and Messaging Editor Search

Edhy Rijo — Wed, 08 Jul 2009 19:52:54 GMT

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 :hehe:.

Thanks both for sharing those experiences.

RE: Localization and Messaging Editor Search

Trent L. Taylor — Wed, 08 Jul 2009 15:50:55 GMT

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

RE: Localization and Messaging Editor Search

Greg McGuffey — Wed, 08 Jul 2009 15:36:21 GMT

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

RE: Localization and Messaging Editor Search

Trent L. Taylor — Wed, 08 Jul 2009 14:20:07 GMT

[codesnippet]My brain still wants to put types after the variable when declaring them and I'm kind of bummed you can't declare/initialize in one step:[/codesnippet]

Truthfully once I got used to it I liked C# better anyway on this. In truth it is actually more readable and still requires less typing because some of the editor features (i.e. the tab after "new" command, etc.).

Anyway, glad you are enjoying it...I have "drank the Kool-aid" so to speak. :D In fact, my first .NET was actually C# before we went into main development and moved to VB.NET...glad to be back! :D

RE: Localization and Messaging Editor Search

Greg McGuffey — Wed, 08 Jul 2009 13:34:57 GMT

I've done some more test driving, this time on another machine. All the weird stuff I previously posed about isn't happening here. So, I must have something weird setup on the first machine. In any case....

I'm liking it! :D

My brain still wants to put types after the variable when declaring them and I'm kind of bummed you can't declare/initialize in one step:

[codesnippet]'-- VB: I like that I can do initialization during declare
Dim boss As New Employ()[/codesnippet]

[codesnippet]//-- C#: have to identify type, then initialize
Employ boss = new Employ();[/codesnippet]

But mostly I'm liking it. Amazing how much some IDE niceties were causing pain (when it wasn't indenting correctly on first machine, especially when using code snippets).

I really like how constructors are handled, were you can identify other constructors to run:

[codesnippet]''' VB: Have to explicitly call other constructors
Public Class MyClass
  Public Sub New()
    Me.New(0, String.Empty)
  End Sub

  Public Sub New(id As Integer)
    Me.New(id, String.Empty)
  End Sub

  Public Sub New(id As Integer, name As String)
    Me.ID = id
    Me.Name = name
  End Sub
End Class[/codesnippet]

[codesnippet]///C#: For a constructor you can just identify what other
/// constructor to call
public class MyClass
{
  public MyClass() : this (0, String.Empty) {}

  public MyClass(int ID) : this (id, String.Empty) {}

  public MyClass(int ID, String name)
  {
    this.ID = id;
    this.Name = name;
  }
}[/codesnippet]

I also found a cool site that compares VB to C# side by side. Very quick way to look up how to do something in the "other" language.

[url]http://www.harding.edu/fmccown/vbnet_csharp_comparison.html[/url]

Thanks for the info and encouragement! I'm looking forward to the new 1.7 release and to doing more in C#! :w00t:

RE: Localization and Messaging Editor Search

Trent L. Taylor — Wed, 01 Jul 2009 13:45:00 GMT

[quote]
Now the language isn't to hard, I'm picking that right up. However, I'm about to start drinking over how the editor is handling formatting.[/quote]

The editor is actually far better once you get used to it and get it setup. I might recommend getting CodeRush from DevExpress. It is horriblly irritating with VB.NET, but works very well with C#. You can make the text editor look a lot better, change how regions looks, colors, etc. And it makes moving to C# a lot easier. You will have to turn off a lot of irritating junk that is enabled by default, like templates...they REALLY annoyed me. But once you get it setup and configured to your liking, it is much better.

But before you haul off and get that, the settings you are talking about are standard .NET options. Click on Tools -> Options and go to the Text Editor options for C#.

All of the frustrations you mentioned can be fixed here. You might add a frustration or two while figuring it out also :D

[quote]I've also read about how you can use Ctl K, Ctl D or Ctl K, Ctl F to format something...I'm not sure because neither do a damned thing.[/quote]

LOL...the Ctrl K+D is something I use a lot...a whole lot. The ONLY reason it will not work is if there is an error within the syntax...or you have your formatting setup to do just what you mentioned.

I am not generally a big fan of too many tools, but CodeRush from DevExpress is really a nice Add-In for VS and makes formatting code, snippets, etc. really nice. You can move methods around between regions, change declaration types, etc. with inline editor tools (if turned on) through this add-on. Check it out, it really is nice for C#. I will tell you this, however, if you leave it on for VB.NET....well...prepare for a few cuss words to pop out of your mouth. :D

RE: Localization and Messaging Editor Search

Greg McGuffey — Wed, 01 Jul 2009 13:36:10 GMT

OK, so I decided to give C# a little test drive. I have a little research project I'm working on and I thought I'd just whip up a C# version.

Now the language isn't to hard, I'm picking that right up. However, I'm about to start drinking over how the editor is handling formatting. :crazy:

In VB, when I type, I don't really even think about things like indenting, it just happens. When I type, it just puts where I want. So, If I type:

[codesnippet]Public Sub TryMe()
      Dim result As Integer
End Sub[/codesnippet]

I get...
[codesnippet]Public Sub TryMe()
  Dim result As Integer
End Sub[/codesnippet]

When I do something similar in C#...
[codesnippet]public void TryMe()
{
      int result;
}[/codesnippet]

I get...
[codesnippet]public void TryMe()
{
      int result;
}[/codesnippet]

and not...
[codesnippet]public void TryMe()
{
  int result;
}[/codesnippet]

* This is with Enable Virtual Space checked

Also, when I use code snippets, it doesn't fix the indentation! Which means I have to highlight the code and manually manage this. Very frustrating.

I've also read about how you can use Ctl K, Ctl D or Ctl K, Ctl F to format something...I'm not sure because neither do a damned thing.

So, what sort of settings might I use to enable the sort of smart formatting I'm used to with VB? I'm not really interested in having to type [u]every single character[/u] exactly like I want it to appear. I'm building apps here, not ASCII art!

:angry:

RE: Localization and Messaging Editor Search

Greg McGuffey — Tue, 30 Jun 2009 11:37:19 GMT

Thanks Trent.

RE: Localization and Messaging Editor Search

Trent L. Taylor — Tue, 30 Jun 2009 07:10:05 GMT

Well, this is easier said than done. It is my opinion that new development is a good place to start. So new classes, controls, etc. would be created in C# instead of VB. I do not recommend scrapping all of your VB code and starting totally over as that would be painful.

VB.NET is a good language and once it is compiled down, there are very few differences (though there are some). In our medical application, we have been writing all new development in C# for a while now and it grows really fast. We still have more VB.NET code than C#, but it is quickly evening out. Then once the release it 100% out the door, certified, released, etc. then we will start rewriting the base classes in C#.

Here is one thing that is important to keep in mind, it isn't bad to have VB.NET code within your application. For example, if you are moving an application over from Visual FoxPro to .NET...yeah, you would need to kill VFP quick as possible! However, VB.NET code is still .NET and a very powerful language, so it isn't like you are running on an antiquated platform.

RE: Localization and Messaging Editor Search

Greg McGuffey — Mon, 29 Jun 2009 18:33:45 GMT

So, the next step: suggestions to a developer to move from VB to C#.

Two areas of interest: how to learn C# and how to migrate existing code from VB.NET to C#. I'm more interested in the second item, as I'm pretty familiar with C# (enough to get started), but I have no idea how I'd actually start using it in an existing project.

RE: Localization and Messaging Editor Search

Trent L. Taylor — Mon, 29 Jun 2009 14:28:27 GMT

[quote]I believe if this was solved, we probably wouldn't be having this conversation. You likely wouldn't have switched and I wouldn't be thinking about it.[/quote]

In truth we would probably still be moving over. Granted, this sealed the deal. The industry standard, especially in the area of development tools, is C# for a number of reasons, many of which not mentioned here just yet. But Microsoft internal teams are very strong proponents of C# over VB.NET. A fair portion of Visual Studio itself is written in C# (the remainder of it is written in C++), but it is geared for tools. Another major reason is that it will actually benefit the framework. If something is going to happen, it generally happens in C# first before VB.NET completely keeps up (some of your other comments elude to this point).

[quote]You can set these up by project in VB. The defaults for VB are to warn for a number of items (unused local var, no return, etc.), but they can be set to throw a error. Likely this is nicer in C# because it is just setup that way for each project in C#, were as you have to remember to go in and change if for VB projects. I haven't found a place to set defaults for this yet.[/quote]

True, but you have to make it instead of exclusive. And to be honest, I have never gotten VB up to the level of C# even when trying. On the flip hand side, I quickly learned how to add warning exclusion tags as part of the compiler commands. I don't have the patience to try and make VB work to this extent for each project, and more importantly, and it is easy to forget and let some things slip few until you remember!

[quote]with the developer thinking that anotherVar would only get incremented if myTestVar == 'somevalue', when in fact it would get incremented every time. This is definitely personal preference and I see you point. [/quote]

Never been an issue in this shop as the code is generally cleaner and easier to read since we have some hard and fast standards. But I get your point. Just FYI, if you look through Microsoft code you will see that this is a common standard...again, a preference and not a reason to choose one language over another.

[quote]OK, that's interesting. Not that I'd ever want to, but how would this work? You write you're own compiler? Modify theirs?[/quote]

Never done it, I just know that you can. Like I said, this is not something that I plan to deal with...soon anyway. I actually am going to mess with getting a C# app to run on Linux, to which there are a number of add-ons and compilers out there for this. I do not plan on moving to Linux, but there could be some long-term applications here, especially in the area of cost and some medical environments that demand certain platforms...so this gives us more long-term flexibility.

RE: Localization and Messaging Editor Search

Greg McGuffey — Mon, 29 Jun 2009 13:48:18 GMT

Great post Trent! Much to chew on.

I do have a few comments. :D

[quote]The design-time compiler is terribly annoying![/quote]
I believe if this was solved, we probably wouldn't be having this conversation. You likely wouldn't have switched and I wouldn't be thinking about it.

[quote]Compiler error handling in C# is far better than VB.NET[/quote]
You can set these up by project in VB. The defaults for VB are to warn for a number of items (unused local var, no return, etc.), but they can be set to throw a error. Likely this is nicer in C# because it is just setup that way for each project in C#, were as you have to remember to go in and change if for VB projects. I haven't found a place to set defaults for this yet.

[quote]Inline immediate if testing[/quote]
I didn't know that the C# version didn't have the performance issues. I've kind of just removed this construct from my brain because it sucked in VB...

[quote]Yielded returns when returning a collection using the IEnumerator interface[/quote]
I did find one article explaining how to use the yield keyword in VB....but it turned out some bone head had just translated an article about yield in C# to VB without actually seeing if VB supported it. It doesn't. It is on the list of features that VB will support but not sure when (maybe 4.0). (Found that info in a MS bug list for .NET).

[quote]Code editor is more RAD friendly, especially when creating new instances[/quote]
This is cool.

[quote]Semi-colon terminates a statement versus having to use " _" to go to another line[/quote]
In .NET 4.0 for VB, you won't need to use the "_" anymore. :D Of course, as mentioned, if they don't get the stupid design time compiler fixed, this is a moot feature.

[quote]C# doesn't require a minor if test to remain on a single line for abbreviated code[/quote]
I've read and tend to agree with the thought that you should always use the curly braces, even for single line elements. The potential issue is that some other developer might miss the fact that you've left out the braces and then you'd get something like:

[codesnippet]if (myTestVar == 'somevalue')
myVar++;
anotherVar++;[/codesnippet]

with the developer thinking that anotherVar would only get incremented if myTestVar == 'somevalue', when in fact it would get incremented every time. This is definitely personal preference and I see you point.

[quote]Can compile an application to run on other operating systems[/quote]
OK, that's interesting. Not that I'd ever want to, but how would this work? You write you're own compiler? Modify theirs?

Finally, thanks for the kind words. While I am a curious individual and really, really like to understand things, I wouldn't have progressed nearly so far, as fact, without the help of both the SF team and all the other contributors to this forum! So thanks to all of you!

RE: Localization and Messaging Editor Search

Trent L. Taylor — Sat, 27 Jun 2009 16:05:35 GMT

Well, let me give my two cents on the languages...and give you some applause. I have seen you really grow over the last few years in .NET and in application development as well! As some may know, it is hard to get a lot of praise out of me at times...but you deserve it. You are teachable and keep an open mind which is one of the reasons I think that you have done so well.

But on to my two cents :D I thought I may as well comment on why we are moving and state of the major reasons and benefits of C# and also point out some of the benefits of VB as well.

Let me start by saying that I like VB.NET. It is a good language and there are many things that I really like about it, so this is no means a blasting of VB, but rather a basic explanation of some, not all, of the reasons we have moved over to C#.

The design-time compiler is terribly annoying!

If VB.NET would deal with design-time like C# versus constantly running the compiler within the design-time. If a project gets very large in VB.NET, the design-time environment can't take it many times and requires the solution to be split apart. We even had to go to the extent of removing project references at this was a major point of failure. On an average day of development we may be kicked out of Visual Studio 5-7 times a day....way to interuppting for production.
Compiler error handling in C# is far better than VB.NET

This can be a big one when it comes to reducing bugs before making it into the field. One of our internal developers most common mistakes in VB was to forget to return a value within a function. The VB.NET compiler may give a warning...but it will still allow it. C# will prevent this and while talking returns, it does a better job of ensuring that all code paths have a return value when required. Another example would be unused variables. C# does a better job of ensuring that a declared variable is used versus VB.NET.
C# requires less code as a whole not requiring unnecessary declarative statements

In this example lets take a property declaration. In VB.NET you have to add the ReadOnly directive in order to make the property only support a get. In C#, you just leave off a set. Less code and easier to change later if adding a set. While on this topic, the whole curly braces controversy generally comes up. In truth, it really is easier to read the code without all of the extra text. Instead of requiring End If or End Property, it is just a curly bracket. This can fall more into opinion, but the code ultimately does look cleaner.
Inline immediate if testing

Technically in VB.NET you can call Iif(...), but it is an added on method for backward compatability and very inefficient. In C# this is a very basic inline test that is one I use all of the time. I had to stay away from inline tests like this in VB.NET due to performance issues...but it really can improve code. For example:

[codesnippet]string myVar = myTestValue == 1 ? "First" : "Second";[/codesnippet]
Yielded returns when returning a collection using the IEnumerator interface

There is no equivelant (that I know of :D ) in VB.NET. In C# there is a yield keyword that can really improve performance when enumerating a collection and returning a collection. This is big, and can be a major improvement in regards to performance in StrataFrame when calling the GetEnumerable() method on a BO. At present we have to create a collection and return that collection. Using a yielded return, there is no need to create a unique collection instance for the return. Here is a good article (http://blog.dmbcllc.com/2009/03/25/advanced-csharp-yield/).
Code editor is more RAD friendly, especially when creating new instances

OK, this can be a long topic and generate a lot of debate. But Refactoring code in C# is WAY better than VB.NET...there is not much of an argument here, natively C# is just much better. Another super awesome feature in C# is the tab after a new statement. C# will automatically, and always, bring up the correct class including namespace if required of the class instance being created. For example:

[codesnippet]MyCompany.MyApp.MyClass class = new (TAB HERE)[/codesnippet]

will produce this without any additional typing:

[codesnippet]MyCompany.MyApp.MyClass class = new MyCompany.MyApp.MyClass[/codesnippet]

You will still have to put the parens and parms, but it saves a lot of typing.
Semi-colon terminates a statement versus having to use " _" to go to another line

This doesn't sound like that big of a deal, but it has turned out to be huge for me! I didn't realize how much additional effort was requiring to do this. In C#, just go to the next line and keep typing.
C# doesn't require a minor if test to remain on a single line for abbreviated code

For example, there are a lot of times that I may be doing a single line of code or execution after an if test. I did this a fair amount in VB.NET but C# does it better.

VB.NET
[codesnippet]Dim myReturn As String = "My Value"

If !String.IsNullOrEmpty(myReturn) Then myReturn &= ":"[/codesnippet]

C#
[codesnippet]string myReturn = "My Value";

if(!string.IsNullOrEmpty(myReturn))
myReturn += ":";[/codesnippet]

The nice thing in C# is that you can do it on the same line if you want to.
C# is the industry standard and the primary language of Microsoft

This is a good reason that C# has a tendency to do more than VB.NET and the editor and RAD tools are better...it gets the most attention. I am in no way talking negatively about the VB.NET team...they are awesome, but C# lends itself to a little more flexibility for this reason alone.
Can compile an application to run on other operating systems

This is not a major reason, as I am not insane enough to write for another operating system like Mac....in fact, I was at Best Buy the other day and had to wash my hands after I touched a Mac! :D But the point I am making here is that you have more control with the compiler which in and of itself can play benefits downstream....but this is no reason to choose C# over VB.NET.
Documentation is actually slightly better in C#

C# does a better job with commenting and documentation. It is also, by default, better about throwing warnings about any public piece of code not commented.
Easier to tie into the API

In C# there are many times that you can get directly to the API versus having to call a bunch of Declare statements. Minor, but nice.

I could actually give a number of other examples, but my family is trying to get my attention to head to church! :D At any rate, I am sure this thread will grow some more and I will post more examples at a later date, but I thought this might help.

RE: Localization and Messaging Editor Search

Greg McGuffey — Sat, 27 Jun 2009 00:40:49 GMT

I was just curious. I had read a lot about the differences between C# and VB.NET and what you were saying was new to me. Because of the research I did as a result of it, I learned a lot about .NET (no matter the language used), so that was cool. I agree that some of VB's naming syntax is...er...annoying. I haven't bitten the bullet yet to do anything significant in C# yet, but the runtime compiler thing is about to drive me crazy, so it may not be too far off. I look forward to checking out the source in C#...always learn a lot from y'all! :cool:

RE: Localization and Messaging Editor Search

Trent L. Taylor — Fri, 26 Jun 2009 15:58:40 GMT

Yeah, I suppose that the Narrowing would be similar. In truth, didn't look too hard as we had already planned on moving away from VB.NET when we were doing this. So I guess this is one of those things that is good to know but in the scheme of things will not make any difference.

At this point I really don't feel the need to investigate it much more, but thanks for the info. ;)

I will say this...VB.NET really did a poor job of syntax naming! This is another reason...we have some new developers and they are taking to C# much faster than VB. We finally had to use C# code to make them understand that a "Friend" is an "internal"....for example. I will add this to the list of poor name choices. :D

Really, had we cared to know, I suppose we could have gone the other way to look up the VB once we had made the C# work...but at that point it had no bearing.

Just FYI...C# will still be the new code base ;)

RE: Localization and Messaging Editor Search

Greg McGuffey — Fri, 26 Jun 2009 14:12:54 GMT

I've been reading up on this and I'm not sure I'm seeing what C# can do that VB can't. In VB you can overload operators (+, -, >, <, etc.) including CType. So, in VB you could do:

[codesnippet]Public Shared Widening Operator CType(m As Money) As Double
  '-- do approrpiate conversion...
End Operator

Public Shared Widening Operator CType(i As Integer) As Money
  '-- do approrpiate conversion...
End Operator

Public Shared Narrowing Operator CType(d As Double) As Money
  '-- do approrpiate conversion...
End Operator[/codesnippet]

I just created a sample app and I don't think there is any difference between VB and C# related to this. Narrowing conversion can be implicit, but widening conversions must make the conversion explicitly:

[codesnippet]
'-- This works because money has a Narrowing CType() operator
'   between integer and money
Dim m As Money = 34

'-- Likewise you could assigna money value to a double
Dim d As Double = m

'-- But if you wanted to do the reverse, you'd have to use
'   an explicit conversion
Dim m2 As Money = CType(234.5334, Money)[/codesnippet]

C# can't do narrowing conversions implicitly, can it? Am I missing something?

Thanks for taking the time to respond to this also, as I'm learning a lot. This is yet another reason SF and this forum rocks! :D

RE: Localization and Messaging Editor Search

Trent L. Taylor — Fri, 26 Jun 2009 09:52:53 GMT

Just wanted to clarify one thing on this as well, doing this type of conversion should only be used in rare circumstances...but this happened to be one of them. :)