It sounds like you have something in your code, possibly a user control or dialog that is creating an exception. Are you inheriting the MFTS or using it as is on your dialogs?



It does smell of an exception which could even be the inability to properly query the localization key which is embedded in an assembly. Have you checked your assembly references making sure that you don't have some point to 1.7 and others pointing to 1.6?

I created the new app and have no issues with the MFTS. So, my solution which is made up of 12 projects is messed up somehow? I'll need a nudge.



BREAKING NEWS!



I decided to open up my solution and count the number of projects in it so I could respond above. When the PackingList form came up, it was FINE! I closed the solution and reopened it several times after the initial discovery of the UI string problem. Each time I opened it, the forms were incorrect. This time, after I created a new project in response to your suggestion, the form is correct. THEY ARE ALL CORRECT, NOW! I just spot checked a few more.



So...what just happened here?

There is something going on within your environment. Let's start with basics. Just FWIW, this code hasn't changed since version 1.5 of SF. So I really don't think that SF is doing anything here, otherwise the entire SF user base would be reporting this same issue.



Your localization environment of your application could have an effect, but I am going to need more details to help you work through this. If you look at the SF source code, the privates attempt to retrieve the localization value.



For example:







This is done at this point to allow the value to be overwritten via the designer. So it sounds to me like you have one of several issues going on. Before I get into each point, do the following:



1. Create a new SF application

2. Create a form and drop on a Maintenance Form Toolstrip

3. Build the project

4. Run the project

5. Get out of VS

6. Re-open the dialog with the MFTS

7. At this point, are the values showing the UI_New, etc. keys?



if the above did not fail, then you have something going on within your project, if not, then you have something going on within your development environment. This will help to know which way to nudge you.

Is there any explanation for this? I do not want to revert any of my files to a previous revision. Not for this problem. The problem should NOT have occurred. Toolstrip customizations are a StrataFrame thing. How did I trigger a solution-wide revision of every toolstrip to use some kind of default localization-like constant?!? I'll admit, I probably did something to provoke this; however, I doubt it.



Btw, I did revert the file to a previous revision. Scary...it did not change back. The UI strings are still showing up incorrectly.

I picked one form to try to figure out what is going on...it is the PackingList.cs form. The last revision on the form is Tuesday, July 7th at 6:21pm. The stored revision is well before the update that I made to 1.7.0 (including the update to DevEx). The designer file matches the current working copy EXACTLY. Even if I revert to that revision, nothing will seem to change.



Stumped.

Unbelievable.



ALL, and I mean ALL, maintenance form toolstrips are now showing the same thing (UI_New, UI_Browse, UI_Edit, UI_Delete, etc.)!







All I did was make a change to a report and added some small code changes to a button on one specific window. Then, I posted the code to the server. When I went back into my code to look at working on another change that a user requested, I encountered the text changed on the buttons on the toolstrip on the form that I wanted to edit. I checked on a number of other forms that have the same toolstrip. They all have reverted to the same thing. UGLY! I do not know when this happened.



This is now a huge problem...either I revert EVERY form back to a time when the form was correct (via code source) or I manually change EVERY form and fix the text on each property. Either way, the situation is grim. I already posted the updated code to the server. Users are downloading it and updating their clients as I am writing this. I cannot stop the rollout. They are going to have forms that look TERRIBLE!



What am I doing wrong? Why did this happen? Is there a solution to this somewhere? I thought I had this solved. But, I guess not.



Is anyone else running into this? If so what did you do to solve this problem?



Any help is certainly appreciated!

Cool

The suggestion that localization had changed in some way was only a guess on my part. The assemblies were out of whack which has caused a ton of problems in my code. This specific issue is resolved. Thanks!

OK, it looks like you do not have all of your SF assemblies on the most recent version. It was not able to pull the localization text from the MicroFour StrataFrame UI assembly. Most likely this is what happened.



1. You loaded SF 1.7.

2. Not all assemblies were updated (as shown by some of your other screen shots).

3. While having reference issues, you opened a form designer with an SF Maintenance Form Toolstrip.

4. Since the old assemblies were either in the AppDomain or still in the GAC while other SF assemblies were in the references or AppDomain, the designer attempted to re-serialize the values.

5. Thus you were stuck with the UI_ labels.

6. Going back to source control would resolve this issue since the serialized text was showing as overwritten....or right-clicking the text and resetting it should have worked as well.



FYI, the localization for all of this HAS NOT CHANGED. I noticed that you made a comment in regards to localization changing. It hasn't nor have these keys.

Please look at the images I attached on the initial post.