Bill Cunnien
|
|
Group: Forum Members
Posts: 785,
Visits: 3.6K
|
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?
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
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?
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
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?
|
|
|
Bill Cunnien
|
|
Group: Forum Members
Posts: 785,
Visits: 3.6K
|
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.
|
|
|
Bill Cunnien
|
|
Group: Forum Members
Posts: 785,
Visits: 3.6K
|
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?
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
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.
|
|
|
Bill Cunnien
|
|
Group: Forum Members
Posts: 785,
Visits: 3.6K
|
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.
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
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.
|
|
|
Larry Caylor
|
|
Group: Awaiting Activation
Posts: 592,
Visits: 3.7K
|
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.
|
|
|
Edhy Rijo
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
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.
Edhy Rijo
|
|
|