I would like to create a multithreaded Usercontrol with C#.
Is this possible with VisualStudio or only in C++? The idea behind is to initiate several instances of the control, so that each instance has its own memory segments and works inependent from the other instances...
Background:
I would like to use the control within SAP. In SAP I am able to create multiple instances of SAP GUI. Each SAP GUI instance contains my own (ActiveX) control. The example is a stop watch. Currently i start the stop watch in the first instance and all other instances are in sync. This is fine so far - but now I would like to change the UserControl (which is obviously a STA DLL) to an MTA DLL so that each instance of the control has its own time... Do I have any chance to compile it as an MTA DLL or is this not solving the issue (without changing the architecure)? Or am I completly wrong?
Assumption: The stopwatch is GDI based... The actual error which I am seeing is from code inside GDI+ that ensures the same Graphics object cannot be used in multiple threads. But how can I use the graphics object in multiple threads?
Base on the info you provided, yes you can, but for memory segment, its per process not controls inside the process, for 32-bit applications, max is 2GB, can be extended to 3GB but not recommended.
if you want independent memory then you must create multiple executables where each exe has its own address space.
so what you can do is create a C# application that has usercontrol or form and add your logic, this will be compiled into a separate exe, then create another C# application to start a process(es) for the first C# application.
Related
I am working on a small engine which can be run as standalone or within a winform application.
So far I got both working, the only issue I have is that during debugging in visual studio, the winform application's gamescreen updates slowly, which results in the player lagging.
But if I open the created .exe without the debugger, it runs smoothly.
So that I can easily edit the winform, see my changes and play the game without lag I am asking you guys if you could help me.
You can see my code here:
https://github.com/insanepure/SweetEngine/
Sweet.Editor is the C# Winform, which depends on the Sweet.Wrapper, which is the managed C++ application. This depends on Sweet.Game (for game specific components, also that can be run as standalone) and Sweet.Engine (which depends on Sweet Core etc but I abstracted that so that you only need to include Sweet.Engine within Sweet.Game)
So the tool works is that it get's the HWND of a specific Panel and then creates the engine with that HWND, instead of creating a new one. That is the only difference between standalone and tool.
The problem may be because I am running my own loop within SweetEngine. I tried to change this so that the winform calls Update and Render, but this somehow was slower than doing it in a seperate loop.
Also I am not sure why this is faster than making the application call Update and Render.
Another problem I encountered is that I can't debug my native c++ code, so I can not step inside of it. Can this be fixed somehow?
Switched to WPF and using a class that inherits from usercontrol, that way I can draw when OnPaint() is called, also I am using a timer to call OnPaint 60 times a second. Now it's working better.
I want to learn how can i run a external program in my c# form.
with these speccifications:
FormBorderStyle = none
Size and Location fixed.
You cannot run an external process within your own. You can start one, but it's gonna run on its own and you cannot access its internal behaviors. However, if your goal is to use a class (like a form) from another .exe or .dll, you can do it by referencing it in your solution and creating that instance like any other. But if that form is already controlling its own location, size and so on and doesn't allow to be modified, you're kinda stuck. You could force it with some reflection, but the behavior might be highly unpredictable.
I've been asked to create a little tool to help automate a basic 3rd party WinForms application.
So far I've managed to overcome many hurdles but this one is by far one of the most frustrating of them all (And spending 8 hours researching only to find out LVM_GETITEMTEXT was returning an LVITEM struct with 64-bit pointers was very frustrating) - I can't seem to find any way at all to get any kind of reference to a ToolStrupStatusLabel in the third party application's StatusStrip.
The only indication I have that the application has finished it's assigned task is when the StatusStrip is updated to show it has been finished. I can't reliably automate it's operation if I can't find out when it finishes one job and proceeds to another.
Is there any message I can SendMessage() to the application? Any function I can call? Anything that will help me locate the text on this label so I can gain some insight into the application's status?
The automation tool is programmed in C#/Winforms with pInvoke for various Windows functions. I've also created my own DLL in C++ to assist with obtaining data from the LVITEM struct, so C++ workarounds are possible too.
This isn't going to work. The ToolStripItem derived classes are special, they do not derive from Control. They don't have their own window handle, they use the window of their host to draw themselves. Where the host is a Control, like ToolStrip or StatusStrip in your case.
This makes them unusable from traditional UI automation tools that require a window handle. The only way to commandeer them is by injecting a DLL that uses reflection to get a ToolStripItem reference. This exists, the Managed Spy++ tool uses this technique. Source code is provided so you can put your own together, you'll want to leverage the ManagedSpyLib which does the heavy lifting.
I am creating a video player application with a UI in C# and the video decoding and display (DirectX) in C++.
The C++ code is compiled as a DLL and interfaced with the C# UI.
To maintain the correct display frame rate I need to create a secondary thread either in C++ DLL or C# which can do accurate timing and call the display function at right intervals.
However, creating a secondary thread which posts display to the window created by the primary thread (from C# GUI) creates access violation and results in a crash.
However, if I use a timer object in C# to display, the player works but I am unable to maintain the right frame rate due to it's coarse granularity.
What would be a good solution to handle this?
I think the crashes you experience are caused by the fact that you can't access Windows Forms controls from outside the main thread.
Consider using Control.Invoke() to invoke the execution you need on the main thread.
Bear in mind though that Control.Invoke() uses Windows' message queue to pass the request through, so expect some inaccuracies.
When using Office Interop in C#, if you insert a chart object into a MS Word document, the Grap application loads up very briefly and then goes away. Is there a way to prevent this from happening? I have tried setting the Visible property of the application instance to false to no effect.
EDIT: The Visible property does take effect when used against Word when interopping, and it does not pop up. I would expect there is a similar way to do this for MS Graph.
This is common behaviour for a lot of component hosted in an executable binary. The host application will startup and then do the job. I don't know if there is a surefire way to prevent that since you have no control over the component nor over the process until the application is started and is responding.
A hack I tried in the past (for something totally unrelated) was starting a process and constantly detecting if its main windows was created. As soon as it was created, I was hiding it. You could do this with the main module of the faulty application and hope it will be fast enough to hide the window before the user notices. Then you instanciate your component; the component will usually recycle an existing process, hopefuly the one with the hidden main window.
I can't garentee you this will work in your situation, but it's worth a try it the issue is that important, or if you don't find a better way of course.