I had a User Control start doing weird things with its events; it didn't call the load and layout events at all. I looked at the designer code and everything seemed fine. tried recreating the events in the properties windows, and still nothing.
as I didn't have this problem with other user controls i decided to delete it and make a new one with the same name. then it all went haywire - the designer of the main window suddenly stopped recognizing all the user controls and classes i've built for the project.
the design window just shows the same error repeating once for each user control or class:
Could not find type 'Project Name.Class/User Control'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built using settings for your current platform or Any CPU.
I tried restarting the PC, rebuilding all, cleaning solution, deleting the user control that caused the kerfuffle, recreating it, and changing solution to x64 and x86.
edit: it's a windows form application.
how can i get it to work again?
It just randomly started working again. I literally haven't touched it since. but it's solved, I guess...
Related
I have a winforms app (>75k lines of source code), I have just added some new functionality and a new form and I'm getting the 'can't create window handle' error but only when running inside VS. The app builds OK and when i run it as the executable it is using 597 handles, 94 GDI and 83 USER and the new form works just fine apart from my logic errors in it. So as far as I can tell; my app is well below the 10,000 limit where things start to break therefore the problem is in/with VS somewhere but I may have hold of entirely the wrong end of the stick or possibly completely the wrong stick.
I have cleaned, rebuilt, rebooted etc and it stills falls over.
I'm using Process Explorer (thats where the previous numbers came from) but can't seem to find VS in there to check what its total handle count is.
VS2017 on Win 11.
Yes, I have googled it and explored things to look at but I can't find a result that matches 'Studio falling over but the exe running fine', any help / pointers very much appreciated as I obviously can't debug the new form which does make things somewhat difficult.
The underlying issue was to do with a pop-up form being generated by the parent form during its load processes, I found that the parent hadn't been issued a handle before it was trying to show the pop-up. Before you ask... I'm capturing data from a network sensor via the pop-up, which, once the user has accepted the incoming value, feeds the data back to the parent form. I assume that in run-time everything runs faster and it doesn't hit that 'un-coupled' point. Changed the code in the instantiate/load/shown cycle it runs and all is well.
Thanks once again Hans, headache solved.
I'm working on a Windows CE project and have run into a strange problem. When i display a messagebox the physical key stop working. The project relies solely on key input which work fine when changing focus between objects on the form. Because i can't slect an option from the message box, the application basically locks out.
I initially thought my keydown handler was to blame but i discovered the same issue regardless of the keydown handler (even in a new project it doesn't work)
I've been looking around online for information but the only thing i've come across involves changing messagebox buttons. The most prominent solution is to create your own messageboxes but it seems like a waste for what i need. Is there a more efficient way of solving this problem?
Most simply explained, when I edit, delete, or add code into my XNA project, it does not respond. This is to say that I can comment out the entire Update method of my game and it will run as usual. This also means that the game is stuck at a certain time in development, and can not be edited. I've tried reopening my project and it does not help. I've had this problem before and it is incredibly infuriating and frustrating.
http://puu.sh/1kD6P
This is an image where I have commented out the Update method and would normally never be able to run with 66 errors. But it does run.
In the past I have had to create new projects and drag all of my art assets over and copies of the code. That is the only way I know to fix it, but this has happened with every one of my projects (even on a different computer before).
Anybody know what's going on?
Have you tried rebuilding it from the build menu, not just clicking the debug button?
I have an assembly which generates a Form (it is a client-software). I can build an app getting and starting (Show) that form without any problem. But I cannot start that Form twice because the assembly does not provide a clean capsuled solution. Every second start it would crash because several things will not initialize successful a second time. Unfortunately that assembly cannot be modified.
Now I have put that in a seperate AppDomain to be able to unload that assembly. This works fine and the hosting application can now start that Form multiple times.
Now the problem is: I have a WPF-app which should not show that assembly's Form, it should contain it in one of its own windows. The WinForms Form of the assembly is already in a WindowsFormHost and WPF-Window (with AssemblyAppDomain). But I cannot assign the WPF-Window as Content of one of the main WPF-app-windows. It is in the AssemblyAppDomain AppDomain (and object space is not shared with that).
As far as I searched up to now it should be possible to establish a connection between two WPF windows in different AppDomains because that is kind of the way System.AddIn works. Should work with a Pipeline, Contract and FrameworkElementAdapter. I am somewhat stuck and any more specific hints will be appreciated!
Have you checked the docs about WPF addins? Also check out this example.
C#, VS2010, WinForm application:
Sometimes I do have the problem that I get an error message when opening some of my controls / forms. All code compiles and the application runs properly. Opening the control in the designer gives me:
The designer loader did not provide a root component but has not indicated why.
From my experience I can tell, it is usually something in my code which does not get properly initialized, e.g. a property is not set which is somehow available at runtime, but not when opened with the designer. The only issue is, that the root cause is hard to find.
Q: Is there a chance to somehow use the debugger when the designer opens my component in Visual Studio 2010? That would help a lot and the problem tackling is most likely a matter of minutes then.
Remark: Just to make this clear, I know how to use the debugger ;-), I only have no idea how I could tell VS2010's designer to open my control in Debug mode.
As of 2nd SEP 2010 added:
Thanks for your help. Basically it is the MSDN Library article describing how to do it.
I have managed to set it up and run the second instance
(there was not much to understand how to do it).
It only fails in my case, because the 2nd VS2010 instance (debugging Design Time) fails to find the
symbols for my custom control. I have added the symbols manually under Debugging / symbols. No
result, still "Breakpoint won't be hit because of missing symbols"
BTW, using this approach it is helpful to exclude some stuff from the symbol loading (via modules window), because this will safe a lot of time.
Now if have to figure out how to get the symbols resolved and then I can tackle the issue.....
The vast majority of design time problems with custom controls are caused by code in the event handlers or method overrides in your control running at design time as well as run time. That's normally desirable, you get instant feedback when you change a property in the Properties window for example.
But not desirable when the code depends on something that's available at runtime but not design time. Like a dbase connection or a file that's stored in the build folder. That can generate exceptions and Visual Studio isn't very robust against handling exceptions at design time. Worst case, you can crash VS to the desktop without any diagnostic. But anything is possible.
Review the code in your control and make sure that the bits of code that should only run at runtime are wrapped like this:
if (!DesignMode) {
// etc..
}
Hard cases can be diagnosed with the debugging tips in this MSDN Library article.
To debug your control in design mode, you need two instances of Visual Studio. In the first instance, open the project which contains this control source code. In the Project Properties, Debugger, set command line which calls another Visual Studio instance (msdev? don't know exactly for VS2010 - take it from the shortcut), Then execute "Start Debugging" command. Another Visual Studio instance starts. In this instance open client project which uses your control on the form.