For my project I'm using a combination of C# UI and C++ DLL as "worker".
My Application uses the Irrlicht Engine for rendering. A panel in my C# window is used as Container for the Scene.
Currently I'm implementing an event receiver for mouse interactions. My Problem, the C++ Code don't receive events.
I worked out the core problem: It's necessary, that I'm using a rende loop, that the C++ Code have the chance to catch the event. For this loop I must use a Thread, otherwise my C# window gets freezed. Now the issue, the events don't gets send to my receiver, because the events are from another thread.
Irrlicht System Messages Handler
if (msg.hwnd == HWnd) //My issue msg.hwnd = Main Thread HWnd = Render Thread
{
WndProc(HWnd, msg.message, msg.wParam, msg.lParam); //On this way my event receiver would get the event.
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
Now I must found a solution, how I can contiously render and forwarding events from main Thread to render Thread.
My current work around is the dirty way:
C# Code
while (!RenderStop) //bool to stop this loop
{
MyDll.RenderScene(); // Calculate and redraw changes
Application.DoEvents();
}
It's no good way but with this I'm getting an fake parallelism and the events reachs my DLL.
Ps. All events are just simple MouseMove or Click events.
I would try to do as follows:
Define additional method in your worker that would be responsible for handling events, for example: HandleMouseEvent.
Run worker in the separate thread.
Subscribe mouse events in the main UI thread.
When a new event is raised call MyDll.HandleMouseEvent.
I don't know what RenderScene actually does. However, please note that HandleMouseEvent and RenderScene methods would be called in different threads. It means that you may need to synchronize access to data structures used by your worker (MyDll).
Another solution might be to use some .NET wrapper for Irrlicht Engine instead of writing it on your own. For example, I've found Irrlicht Lime. However, I have to admit I didn't use it.
Related
My application has ATL-based GUI (CWnd, CDialog,...) and it consists of multiple pages (CDialog). One of these pages is otherwise empty but it has a placeholder frame (CWnd) that resizes with the dialog. Everything is built as x64.
When the page loads, it asks for a control handle from managed (C#) side of the application using COM-interop, and adds the control to the dialog as CWnd that is created from that handle:
Managed implementation simplified:
// Class "ManagedControlProvider"
private Control myUserControl;
public long CreateControl()
{
myUserControl = /*Create some new inheritant of UserControl */
myUserControl.Dock = DockStyle.Fill;
return myUserControl.Handle.ToInt64();
}
Native side simplified:
// Call the managed class. Lifetime of m_pManagedControlProvider
// is ensured elsewhere.
LONGLONG lHandle = m_pManagedControlProvider->CreateControl();
// m_pUserCtrlAsCWnd is CWnd*
m_pUserCtrlAsCWnd = CWnd::FromHandle((HWND)lHandle);
m_pUserCtrlAsCWnd->SetParent(this);
// m_ControlFrame is just a native helper-CWnd the dialog that
// resizes with it a so gives us the size we want to set for the
// managed control. This code is also call in every resize -event.
RECT winRect;
m_ControlFrame.GetWindowRect(&winRect);
ScreenToClient(&winRect);
m_pUserCtrlAsCWnd->SetWindowPos(NULL,
winRect.left, winRect.top, winRect.right - winRect.left,
winRect.bottom - winRect.top, 0);
I have done this multiple times and it usually works exactly as is should. But sometimes, like now, I'm experiencing application hangs without any clear reason. With my current control this seems to happen roughly 5s after the focus is set to some other desktop application.
I have verified that the issue is not in the managed control's lifetime or GC. Also it's reproducible in debug build so optimizations are not to blame. When the hang occurs, I can attach debugger and see that some ATL loop keeps on going but that's the only piece of code I'm able to see in stack (imo this indicates that the message loop is somehow caught in infinite loop without interacting with my code).
Now for the dirties fix ever: I added a separate thread to my managed control that invokes this.Focus() every second on the UI thread. Obviously this is a ridiculous hack but it works as long as I pause the focusing everytime user opens combos etc (otherwise they get closed every second).
What am I doing wrong or what could cause this somewhat unpredictable behavior?
I don't know why or what it has to do with anything, but the application hang somehow originated from WM_ACTIVATE. So the solution was to override WINPROC at the main CDialog and block forwarding of that message. Everything has been working without any issues since then.
I'll not mark this as answer because I don't know why this solution works.
Here is what my code looks like:
private void exportToExcelButton_Click(object sender, EventArgs e)
{
txtBox.Clear();
txtBox.AppendText("Beginning Export...");
ExportExcel(txtBox);
txtBox.AppendText("Export complete...");
}
The problem I am having is that whenever the button is clicked (to execute the function above), only part of the current text in the TextBox (System.Windows.Forms.TextBox) is cleared, and replaced with the first line: "Beginning Export ...".
However once the function ExportExcel(txtBox) is done executing, then the entire text is replaced by the new one generated in ExportExcel(txtBox).
Inside ExportExcel(txtBox); I have several txtBox.AppendText() statements explaining to the user the actions being made.
I have tried clearing the text with txtBox.Text = String.Empty; and txtBox.Text = "";and neither have worked.
Let me know if anything needs to be clarified, thanks.
Looks like you're blocking the GUI thread, preventing the text box from redrawing itself. This is one reason why you shouldn't perform long-running tasks on the GUI thread. Use a background thread instead. That way you leave the GUI thread free to perform important operations like drawing, responding to mouse clicks, etc.
Have you tried the textBox.Refresh , before calling txtBox.AppendText("Beginning Export...").
The method invalidates the control.
On the other hand, if you use a background thread, then you should update the UI only by overriding the Progress Changed event. Background threads are not meant for updating user interfaces. Try searching for Worker threads and UI threads. They correlate to MFC, but the concept is the same.
Also keep in mind the cross thread calls.
I agree with dvnrrs. However if you are unable to do this, try calling txtBox.Refresh();after adding each line of text.
There is another method called Application.DoEvents(); that has a similar behavior, but its use is not recommended since it sort of short-circuits the normal application flow and can cause your application to fail unexpectedly or do strange things.
I have a program that runs a series of methods in other threads within one window and let's the user know what's going on using a status bar. The status bar updates are in the main thread which set's the status bar and then refreshes the GUI. There are several blocks of code in series each looking something like this:
Thread do1Thread = new Thread(Class.Method);
do1Thread.Start();
// inform user
this.status.Text = "Doing stuff 1...";
// update GUI
Utility.RefreshGUI();
// join thread
do1Thread.Join();
Sometimes the status bar does indeed update but often is stays on the first status until the end when it displays the last status. Occasionally is sticks on "Ready." which is the default.
Note that two of the blocks take a few seconds so there should be time for it to update. Also, the program is written in C# (Mono) using GTK# for the GUI.
How can I ensure that that the GUI updates to reflect the change?
The problem is that the Join() call blocks the UI thread which blocks all window messages.
Can you use a BackgroundWorker and execute whatever code you have after the Join in the RunWorkerCompleted call?
You need to dispatch Update message to UI thread, call invoke instead of direct property
this.status.BeginInvoke((Action)(() => this.status.Text = "Something happen"));
The best way I have found to update a control in a primary thread is to set a delegate for updating and invoke that from other threads.
You have to use observe and observable pattern.
EDITED:
It is really better divide logic and view parts of code.
Here is an example in real world how to use. Pattern
Could you check whether you are using a StatusStrip control?
If so, your code looks like setting directly the Text of Stautus Strip Control
this.status.Text = "Doing stuff 1...";
So it wont reflect in the Status Strip as Text. You have to place a toolstriplabel and need to set its text in this case.
Please check the post here
I have a C#/XAML Windows Store App and I need to be able to perform some network/RESTful API tests in the resume handler to make sure that a token/session is still valid. If it isn't, the app needs to direct the user back to the login page.
I've tried a number of solutions on SO and for one reason or another, they won't work from within App.xaml.cs. The overarching issue seems to be my inability to get to Frame.Navigate from within the resume handler.
public App()
{
this.InitializeComponent();
this.Suspending += OnSuspending;
Application.Current.Resuming += new EventHandler<object>(OnResuming);
}
private async void OnResuming(object sender, object e)
{
bool success = true;
// some tests are performed here
if (!success) { /* what do I use here? */ }
}
I've tried solutions on the following pages:
Run code on UI thread in WinRT
http://social.msdn.microsoft.com/Forums/windowsapps/en-US/6228490a-0fd8-46ce-adc6-b8d161eeec68/update-ui-when-using-threadpool?forum=winappswithcsharp
Request UI navigation using PRISM 4 on an asynchronous WCF response thread
WPF/C# Don't block the UI
In your example your handling the Resuming event from within your Application class as opposed to somewhere else. You can attach a resuming handler anywhere even within your application pages.
This example from MSDN (How to resume an app) binds the resume handler directly on the MainPage class where you should have no problem accessing the Frame.Navigate method. You could even create a PageBase class which adds this resume handler automatically so all of your pages can take advantage of this functionality.
Another solution is to just grab the root frame. The default WinRT sample app uses the following:
Frame rootFrame = Window.Current.Content as Frame;
So you should be pretty safe doing the same thing. Though you said that you were unable to get to Frame.Navigate for some reason so I'm not user if this is something you've already tried.
The main thing is to make sure that you're not blocking the UI thread at all. The Resuming event is not called on the UI thread so it won't block it by default but make sure you take advantage of async/await anyway, and use the Dispatcher to update any of the UI.
Now unfortunately due to the fact that WinCE Usb Device Arrival / Removal exposes itself via WindowsMessages I have to ensure that a certain (non-UI) component is not created on a background thread. I would like to assert this via an exception but am lacking the code for the assertion.
This component creates a MessageWindow* and uses it to receive usb arrived/removed messages. The issue is if someone creates this component on a background thread (not necessarily; IsBackground = true) when the thread exits the window will be destroyed.
Any ideas?
*as an aside I still don't know why Form doesn't inherit from this class
Update
I think my version 1 wasn't very clear. So this is v2.
When you create a MessageWindow or a Form for that matter on a thread, when that thread exits the Window/Form is destroyed.
My component is creating a "hidden" message window to intercept some important events, ergo I do not wish for it to be destroyed. Therefore I must somehow ensure that the code that creates the form is running on the "Main UI" thread.
If possible i'd like to avoid passing down a reference to the "main" form to this component as it is (architecturally speaking) supposed to be miles away from the UI.
Update
Moving logging question to a separate Q.
Ok, I understand that you don't want for your component to "know" about the main window -- makes sense.
How about this: How about if you make sure that you always instance your component on the main thread? You component will create it's listener window on the constructor's thread.
If you do that, then you just need to make sure that you call the constructor from the main thread. I'm making some assumptions about your code, but I'm guessing that you must have some class in your architecture that knows about both the UI and your component. Create your component there, using a callback, and the main form's InvokeRequired/Invoke methods.
In forms, you use the InvokeRequired property.
Why not create the non-UI component on a background thread and when you go to update any UI component just look to see if invokeRequired then get back on the main thread to actually do the update.
You should have nothing really tying up the main event thread, IMO.
You can use it in this way:
void MyCallback()
{
if (form1.InvokeRequired) { // form1 is any existing gui control
form1.Invoke(new Action<>(MyCallBack));
return;
}
// your logic here
}
Hey there: I had an idea about your problem. This is just a random thought, and I don't know for sure whether it will work (I have not tested, nor even compiled this -- it just hit me):
What if you get the window handle of the main window of your app, then build a Control around it (I'm assuming that you have a gdi-based app, like Winforms)?
this code might not compile, but it's close (it would go into your component -- note that it would make your component require a gdi windows/winform app, as opposed to a console or WPF app).
If you do try it, I'd love to hear whether it worked for you.
using System.Diagnostics;
using System.Windows.Forms;
void Init()
{
// get handle to the main window
intPtr mainWindowHandle = Process.GetCurrentProcess().MainWindowHandle;
Control mainWindow = Control.FromHandle(mainWindowHandle);
if(mainWindow.InvokeRequired)
mainWindow.Invoke(SetupMessageWindow);
else
SetupMessageWindow();
}
void SetupMessageWindow()
{
// do your thing...
}