I'm just getting into Strataframe... I've been working through a lot of the tutorials and I'm looking at the Messaging tutorial. Could someone explain the benefits of the messaging component a little more? It looks cool!

Hi Mike,



Well, the benefit of the messaging component is two-fold:



1) If you're localizing you're messages, you can use the localization editor to create the message in several different languages and let the runtime figure out which language to show when it shows the messages.



2) Whether you're using localization or not (and if I remember correctly, you probably won't be localizing), using the messaging interface allows you to remove embedded text from your application. This gives you the following benefits:



a) You don't have to be a developer to change a message because of a type-o

b) You can reuse messages by reusing the key, rather than copying the text multiple places within your application

c) You can associate an event ID with each message, then when one of your users calls you and says, "Hey, I just got message #157," you know exactly which message they're talking about.

d) You have a central location for managing messages, allowing you to change a message in one place rather than trying to do a "Find and Replace All" in your code



There are other benefits as well, such as the MessageForm being much prettier than the standard .NET MessageBox and the ability to use RTF formatting in your messages.



Hope that helps

There are a number of benefits to the messaging.  There are two distinct reasons...localization (multi-lingual) and externally stored messages.  We add a third part, a custom messaging interface that replaces the ugly old fashioned MessageBox.  Our message box accepts rich text format or HTML and can be sized and supports items such as embedded images and hyperlinks.

If you'll notice, there are two types of values in the messaging editor: Messages and Text Values.

You can call our message box directly in code and hard code the message, or pull from a key (or record) that is created within a Localization and Messaging project.  The Messages type shown in the image above is the type used for our message box.  The Text Values encapsulate everything else, such as labels, title bars, broken rule messages, etc.

Example Message
You can get more details on the localization and messaging in the documentation under Contents -> UI Layer -> Messaging and Localization.  But to emphasize my point I will create a quick message and show you how to call it.  In the Message Editor, you generally want to create a project for each application, but this can be setup however you would like.  In this case I created a messaging project called "MyProject" and I made sure to edit the "English" and set it as the "Default Region Code for Selected Language."

The output path is where the XML files that are generated will be created.  For this example, I just sent them to a temp folder, but you would generally want this to be a legitmate folder.  Once I create the profile, I click Save and modify the project. You can always add another language by clicking the properties icon to bring up the project properties.

I am going to create a message with a key name of MyTestKey.  See the image below for the property settings.

Save the message and let's export and call the message from code.  The messages will be exported to the path that we specified above in the Output path.  We specified c:\temp, so this is where the files will go for my example, adjust all paths below accordingly.  Also, if you are pulling the messages from SQL Server, there is no need to generate the XML files.

Generate the XML files by clicking the "Generate Files" toolstrip button and Select "All languages" when prompted.

We have now created the messages, now let's call the message in code.  Open any StrataFrame project.  We will assume VB.Net for this sample, so once the project is open, select and open the AppMain.vb file (program.cs for C#).  Navigate to the InitApplication method.  There should already be two lines of code related to the messaging:

MicroFour.StrataFrame.UI.Localization.MessageKeyType = MicroFour.StrataFrame.Messaging.MessageKeyDataType.XML
MicroFour.StrataFrame.UI.Localization.MessageLocaleID = MicroFour.StrataFrame.UI.Localization.GetActiveLanguage("YourApplicationKey")

But we need to add one more line of code that specifies our path to the messaging files.  Obviously this can be dynamically set at runtime, but for our sample purposes we will just hard code the path.  So it should look something like this when finished:

MicroFour.StrataFrame.UI.Localization.MessageXmlPath = "C:\temp\"
MicroFour.StrataFrame.UI.Localization.MessageKeyType = MicroFour.StrataFrame.Messaging.MessageKeyDataType.XML
MicroFour.StrataFrame.UI.Localization.MessageLocaleID = MicroFour.StrataFrame.UI.Localization.GetActiveLanguage("YourApplicationKey")

Now all we have to do is call the message box.  So on a StrataFrame form, add a button and place the following code:

Me.ShowMessageByKey("MyTestKey", "Here is the dynamic data that we have passed to the message window.")

Run your project and click the button and you will see the message box.  Obviously adding another message is much easier since we avoid many of the steps and use the same project. 

Keep in mind that if you are going to have very many messages, it is highly recommended to use SQL Server instead of an XML file to store your messages.  You can use the Database Deployment Toolkit to automatically create and deploy your Messaging structures.

I hope this helps

A walkthrough on using SQL would be helpful also, I've been messing around with it all afternoon without much success. Seems much better than using the XML.



In particular, areas I could use how-to advice:

1. Database Deployment -

Where should messaging tables be built? (Yes, I found an option to include them in my development DB, it added MessageItems and MessageLanguages. Is this the correct approach?)

How do I go about deploying them? Seperate Deployment data tasks for each?

If So - Suggestion for future: Allow a single check box to deploy the language info w/ the language tables, as part of the task to add the message tables



2. Message Entry/Creation

So Ok, now I have a DB with the tables in it - How do I fill them in?

Open the Message Editor, how do I get it to use my "new" tables / database? If I create a "New" project, it only seems to accept an file path (Would expect option(s) for an existing DB to use). If I switch the Database Location to my app DB, it fails in trying to use the "Common Repository"



3. What needs to be done to get the forms to work?

Sure, I can fill in the

MicroFour.StrataFrame.UI.Localization.MessageKeyType = MicroFour.StrataFrame.Messaging.MessageKeyDataType.SqlServer;

MicroFour.StrataFrame.UI.Localization.MessageDataSourceKey = "MyDataSourceKey";

But this seems to be way too late, now I can't set the localization keys within the UI. And doing them all by hand would quickly take this out of the usable category. I did look for a "Localization Database", didn't really find a "localization settings object" or anything really like that. The StrataFrame Project Prefs does allow specification of a Project, but doesn't seem to pick up the XML info, only reads values within the project. I had tried using the "Common Repository", but they don't show up within the search in trying to assign them to a control - Is this by design? The values ARE present in the XML, but the drilldown from localizationkey doesn't seem to be using the XML info, rather just the "local" project info...



Messaging & Localization area in the Help (Within UI Layer) doesn't seem to have much information as to what needs to be set up (From a developer level, at least) to get the project to use a data store within a database.



So just really confused, I guess, hoping for some kind of guidance.

1) The messaging tables can be added to any database that is deployed with your application.  As for including the data with the localization tables, there is a new wizard in 1.5 that will create the deployment data packages (and add the localization tables) for both the localization and security.

2) You will not need to "point" your project to your DDT profile becase the DDT profile will contain the deployment data packages to gather the messages when a new package is created for the DDT.

3) When you set the solution preferences to point to a specific project, the localization type editors will search within the project for a key matching the key and/or value you specify.  Once the "LocalizationKey" property is set on a control, the control will retrieve the appropriate value at runtime for localization by searching with the localization store for the text value matching the key that is set as the LocalizationKey property.