By Bill Cunnien - 7/30/2009
I have attached a screen snippet of a maintenance form. I also included a snippet of the properties for the MaintenanceFormToolStrip. It has "UI_New", "UI_Browse", etc., in place of the standard terms.
What did I do wrong, now?!?
Another setback. I cannot post the application updates with this behavior.
Help, please,
|
By Charles R Hankey - 7/30/2009
Is this 1.7 ? I notice in the What's New there is talk of the new assemby UI.Expanded (or at least I think that is what the docs are saying) but I did the install and I do not have the dll and Expanded doesn't seem to be part of the UI assembly.
Perhaps a glitch in the install? (may be a non-issue if so as I think Trent said he was posting another build and I don't see a forum notice yet)
|
By Bill Cunnien - 7/31/2009
Yup... 1.7.0. I think localization changed a bit somehow. I am looking into that angle, now.
|
By Bill Cunnien - 7/31/2009
I have attached the localization editor's version about box. I assume that it is supposed to by 1.7.0. Also, my output folder is referencing the GAC and a 1.6.0... folder. When I choose to "Open Output Folder" I get this friendly message:
Win32Exception
The system cannot find the file specified
Source : System
Stack Trace:
at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start()
at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start(String fileName)
at SFMessaging.MessageEditor.cmdOpenOutput_Click(Object sender, EventArgs e)
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativewindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativewindow.WndProc(Message& m)
at System.Windows.Forms.Nativewindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Of course, I expected a message like this since the 1.6.x was totally uninstalled and wiped from my computer before I installed the 1.7.0 version.
Not sure what to do. Guess I will try reinstalling 1.7.0 and see if it fixes anything.
|
By Charles R Hankey - 7/31/2009
When I installed 1.7 I had to manually redo the references in my apps to the 1.7 in the GAC - especially to Base.
I found the UI.Expanded but only as a c# project in source that doesn't "quite" compile - i.e. it shows 90 errors and 14 warnings but there is a dll when it is done with the compile data time and that dll can be referenced directly from the bin folder but doesn't seem to add new controls to toolbar.)
Anyway, I would be within the next 24 there will be word from Amarillo lifting the fog.
|
By Bill Cunnien - 7/31/2009
I reinstalled 1.7.0 from the most recent post on the website (7/29 around 10am). I blew away the messaging files to make sure the localization would behave better. Even after the reinstall, the messaging stuff seems to be stuck in 1.6.0. I have attached three screen shots of the properties of the various files involved. Unless I am misunderstanding, shouldn't these all be referencing an assembly version of 1.7.0?
|
By Bill Cunnien - 7/31/2009
Just FYI, reinstalling 1.7.0 reset the Inherited UI to 8.2.8. Watch out for that little baby.
|
By Bill Cunnien - 7/31/2009
I am dying here.
It wasn't just the fact that DevEx 8.2.8 was being used in the code. There are other problems, now.  I have attached the most recent popup window when I simply double-click on the PartsMaintenance.cs file to open it in the designer. Opening other windows presents the ugly IAC (Ignore and Continue)!
I am doing my best to get through this. I am now going on a week. It feels like this is all I have done.
Oh, ya...it is all that I have done this week. 
|
By Bill Cunnien - 7/31/2009
Close Visual Studio 2008 and reopen the solution. That got me back to editing in the designer without errors.
Whew! I hate it when it does that...especially, when chasing other errors.
|
By Edhy Rijo - 7/31/2009
Hi Bill,
I feel your pain!  VS sometimes can go south with the instantiation/references, etc. so what I am doing now is for new SF updates, always change all references needed (I use Infragistics), compile that, then open my projects, change references as needed, close VS and open my project and compile.
|
By Bill Cunnien - 8/1/2009
Since I could not figure out why these maintenance form tool strips reverted to using the UI_Text format, I decided to revert all of the corrupted forms back to a previous revision. Source code control is a lifesaver.
My app is running just fine right now. Hopefully, I will be able to move on. It would be nice to know why the tool strips changed. Just so I do not repeat myself next time.
|
By Trent L. Taylor - 8/3/2009
Bill, I don't understand what you are getting at here? What do you mean, UI_Text?
|
By Bill Cunnien - 8/3/2009
Please look at the images I attached on the initial post.
|
By Trent L. Taylor - 8/3/2009
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.
|
By Bill Cunnien - 8/3/2009
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!
|
By Trent L. Taylor - 8/3/2009
Cool 
|
By Bill Cunnien - 8/17/2009
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!
|
By Bill Cunnien - 8/17/2009
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.
|
By Bill Cunnien - 8/17/2009
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.
|
By Trent L. Taylor - 8/17/2009
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:
Private _NewButtonText As String = Localization.RetrieveTextValue("UI_New", "New")
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.
|
By Bill Cunnien - 8/17/2009
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?
|
By Trent L. Taylor - 8/17/2009
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?
|
By Trent L. Taylor - 8/17/2009
Oh, the reason that it worked after you closed the test project is because you did not get out of Visual Studio before you loaded YOUR solution. The SF assemblies were loaded in the VS AppDomain session and did not have to reload...thus it worked on your project dialogs because the SF assemblies had already been loaded. So most likely, after you compile your applicaiton, you will not see this behavior at run-time...just design time. Is this true?
|
By Bill Cunnien - 8/17/2009
The MFTS is used, as is. All assemblies have been verified (several times) and there are no lingering 1.6.x and below assemblies on my system anywhere.
|
By Bill Cunnien - 8/17/2009
The run-time code does not exhibit the behavior. And, yes, I closed the sample solution but not Visual Studio, then I opened my application's solution.
Too much consternation involved here. How do I confirm that the SF assemblies are loaded in the VS AppDomain session?
|
By Trent L. Taylor - 8/17/2009
How do I confirm that the SF assemblies are loaded in the VS AppDomain session?
Write a complex add-in. The AppDomain is the application session domain that holds any loaded assembly. Once it is loaded it remains in the AppDomainuntil explicitly unloaded. VS is supposed to do this when an assembly is rebuilt but sometimes takes a try or two and the occasional getting out.
So it would seem that you have an exception somewhere in your code. Do you have user controls, etc? If you have written user controls and try to query a database in the New or the Load and do not test on the DesignMode flag you could have issues like this.
You might think back to what you had changed in your code when you began to notice the issue. Just FYI, this looks to just be a design-time issue, not run-time. So reverting back to source control versions will have no effect. When it showed up in these tests there was something else going on that allowed the SF assembly to load.
|
By Bill Cunnien - 8/17/2009
I'll skip the "complex add-in".
This all started with the installation of 1.7.0 in combination with DevEx 9.1. No user controls are involved.
I'll start walking through my code to see if I can find some hidden exception somewhere that is not popping up through normal debugging channels.
|
By Trent L. Taylor - 8/17/2009
Well, the issue is that the Visual Studio IDE snuffs most exceptions that happen within the designer...making tracking this type of thing down more difficult.
But the good news is that all of your clients don't have "Ugly" dialogs.
One thing that you can do within your solution is pick a project, then go to the properties and set the DevEnv.exe as a debug EXE for that project. Run that project only, then when over in the new Visual Studio session that gets shelled, you can load up your solution again. But before you do, on the first VS session, do a Ctrl+Alt+E or click Debug -> Exceptions and check the Common Language Runtime Exceptions check. This will stop automatically on any exception at that point.
Not super straight forward but may be one to to see if an exception is being thrown within the VS IDE.
|
By Larry Caylor - 6/3/2015
I know this is an old thread but has anyone ever figured outwhat is causing this. It’s happening on all my developmentsystems (Windows 8.1/VS 2013). I can create a new project, add a maintenance form,and there it is. Everything compiles OK, so I’ve been ignoring it, but it is apain. I would have added an attachment to show what I'm talking about but I got an error message saying I've used up my upload space. Guess I've been around way too long.
|
By Edhy Rijo - 6/25/2015
Hi Larry,
I don't use the MaintenanceFormToolStrip class in my application, but I see some of what is being explained in this thread in the form's property sheet as seen in the attached image.
Like you said, the compiled application just works by resolving these constant but they are not resolved in the IDE whey they used to show up properly a while ago.
|
By Ivan George Borges - 6/25/2015
Hi.
I have changed my SF source code in order to get rid of what Edhy showed on his attachment. Basically I commented the Localization class constructor as it shows bellow: #Region " Constructors " '-- IGB - added on 21/02/2014 - START 'Shared Sub New() ' _isDesignTime = Process.GetCurrentProcess().ProcessName.Contains("devenv") 'End Sub '-- IGB - added on 21/02/2014 - END ''' <summary> ''' Prevents an instance of the Localization class from being instantiated. ''' </summary> ''' <remarks></remarks> Private Sub New() End Sub #End Region If you want, you can also comment the lines in the RetrieveTextValue function in this same class: Public Shared Function RetrieveTextValue(ByVal TextValueKey As String) As String '-- Establish Locals Dim lcReturn As String = "" '-- IGB - added on 21/02/2014 - START ''-- If we are at design-time, then just return the text value key 'If _isDesignTime Then ' Return "#" & TextValueKey & "#" 'End If '-- IGB - added on 21/02/2014 - START I think this could take care of this matter. |
By Edhy Rijo - 6/29/2015
Hi Ivan,
Thanks for sharing this info.
|