I have an application that manipulates with some files in certain matter and have progressbar and textbox. When I debug (VS2010), the app window is not visible, but the app does all the work that it suppose to. If I wanted to create invisible winform application I would probably have to bust my brains out to do so. Now I have one I don't want. How about that? Any ideas how to fix this?
The OP is performing work in the form's initialization phase. During that phase, the form is not yet shown and will not be shown untill all the work is done.
The solution is to move the work code from the form's initialize method to a separate method, that is called only after the form is shown. This method should perform the work on a separate thread to ensure the GUI stays repsonsive, the process can be cancelled and reports back to update the progress bar.
Related
My app written with Codename One involves showing a camera preview In a main form. I have used the native interface implementation to make it work on Android (iOS later).
The app also includes in app purchase to upgrade to full version. That's why a form is shown regularly to suggest the user to upgrade. They can also choose to upgrade later which causes this upgrade to full version form to disappear and make the main form with the camera preview to appear.
Yet on real devices sometimes the upgrade to full version form does not completely disappears and there are reminiscences of it on the main form. In that case the camera preview is displayed on part of the screen and the app buttons do not show. However after some seconds if the user touch the screen the main form gets completely shown and the reminiscence of upgrade form are gone.
It looks like there may be too much things done on the UI thread but I am just calling new MainForm(theme).show() when the user hits the button to close the upgrade form. So this should be OK shouldn't it? Please note that the CN1 simulator does not show edt violation (but there is no camera preview in the simulator).
Or do I have to call revalidate () in the MainForm after adding the components into the layout ? What should I do actually to make these reminiscences disappear ?
Any help really appreciated,
These things are always hard to track but I'm guessing the peer component collides in some way with the new form.
Make sure you don't call postInvalidate unless you really have to and even then you should generally limit and avoid it when possible as it might conflict with our drawing logic.
Also make sure you didn't change the opacity of the parent forms e.g. if you changed the form UIID.
It looks like the solution has been found. Indeed I had a native method that initialized the camera and the surfaceview. I was running this method on the EDT and then showing the new MainForm.
Indeed I embraced the initialization method in an invokeAndBlock() block. Now it looks like the kind of lag is far less visible (I could not see it). In my own logic I can explain it with the fact that the invokeAndBlock() will do the initialization job on a separate thread and when it's fully ready (so the camera and surfaceview are ready to be shown), the MainForm can be shown.
Could it be the actual solution #Shai ?
We've been working on an application for the last few months that's aimed at Windows 7 tablet PCs. So we've used the Surface 2 SDK for most controls and it's all touch-happy.
I have noticed recently, though, that one of our custom controls isn't working as it should. This control provides popout menus, and these are achieved through the Popup control. On a developer's laptop, this works fine and the menus vanish when you click away from them. I've noticed, though, that on our test tablet they have a tendency to stay open.
I found that there was a SurfacePopup in the first Surface SDK, but I can't find one in the Surface 2 SDK. Did they get rid of it? Is there a 'best practice' approach?
If there's no simple solution, I may have to go old-school and add a window-sized hidden SurfaceButton below the menu when it appears, that hides itself and the menu when clicked or touched.
Beyond that I've noticed that sometimes the SurfaceScrollViewer within the popups won't work. I'm guessing this is because it's not picking up touch events properly. I tried adding this extension method to the window..
this.EnableSurfaceInput();
..but I get a NullReferenceException on System.Windows.Input.Mouse.get_LeftButton() which bizarrely suggests that it can only enable surface inputs for controls when there's a mouse plugged in.
Any ideas? They'll all be welcomed with open arms!
There's no SurfacePopup in the Surface SDK 2.0, however you can use a normal WPF popup. Then you need to make sure that it receives Touch Events by using the extension method you suggested above on the popup, not the window:
((HwndSource)HwndSource.FromVisual(popup)).EnableSurfaceInput();
Edit: As I just found out, this only works when the popup is initially open. To get it to work when the popup is opened later on, you don't need to use the popup, but the parent of it's child (see this question).
For the benefit of Daniel, and anyone else who needs a solution to this, I'll try to cast my mind back two years and explain how we got this working.
As far as I can remember, the answer was to use an adorner layer instead of a popup. Basically, every WPF control has an adorner layer, which sits above the control's UI stack. By default it contains nothing, but you can add whatever you like to it.
I got this all working by writing a custom control that allows you to place that control, with content, in the XAML and then show and hide it whenever you need to. When it's shown, it moves its contents into the adorner layer of the containing window, and when it's hidden it moves the contents back into the control itself, which is hidden from the user.
Afraid I can't go into any more detail than that, but as far as I can remember this was the ultimate solution; replacing popups (which never quite worked very well) with a custom control that uses the adorner layer.
Hope that helps!
I have a WPF application which generates MIDI notes (a sequencer).
Besides the UI thread, there is a timer thread which triggers notes. In general, the timing is ok, but I have the following problem: Whenever I do any navigation, the application seems to "block" (i.e. the timer "stumbles" and the output stops for a short time). This happens when I e.g. open a new window or perform a navigation on a navigation window.
This also happens when I navigate to a page which is already instantiated and has been shown before.
Does anyone have any ideas?
EDIT: I think the actual question is: Does anyone know of a way to make navigation faster?
I'm not sure, but wouldn't your eventhandler (_midiInternalClock_Tick) be executed in your UI thread?
So the MidiInternalClock might be executing in another thread, but the handling of the ticks wouldn't. Like I said, not sure about this.
You might want to separate the code that works with the Midi toolkit to a separate class and then construct the clock en handle it's events in a different thread.
If that doesn't help, I'm at a loss. I guess you would then best ask your question on the CodeProject page.
I am attempting to measure the performance for a WPF based application. Currently we have code that times how long it takes to add the content to the WPF render tree. At this point, control is returned to our program. The problem is that there is still a lag before content is displayed on the screen by WPF. For complicated rendering trees, this can be a matter of seconds.
Can you recommend a method to determine when WPF has completed rendering to the screen? I would like these tests to be fully automated and not rely on someone sitting around with a stopwatch.
[update]
Thanks for the suggestions so far.
I have tried waiting for the Loaded and ContentRendered events, but both fire before the content makes it to the screen.
It looks like others are having this issue. I have tried the steps suggested at
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/693fbedb-efa6-413e-ab66-530c6961d3fb/ but still haven't been able force my code to wait for the rendering to complete.
You may use this solution: http://www.japf.fr/2009/10/measure-rendering-time-in-a-wpf-application/
Did you take a look at the WPF Performance suite? You might be able to see the performance and pinpoint problematic code.
You could end the timer after the control's Loaded event since that occurs after the Rendering is complete.
You should use the event ContentRendered of Window.
This will fire every time there's a full rendering sequence, and you can time that.
I'm looking for a way to overlay the graphical output of a third-party application with some lines, arcs etc. The applications accepts a handle of a window in which it will then display its output.
Using VC++ I put together a Windows Forms app in Visual Studio that draws (non-static) stuff in the onPaint-method of a form. Passing this form's handle to the other app, of course, overwrites my graphics stuff every time the other app redraws.
Can I somehow hook into this redrawing process to add my graphics after the other app redraws? Overlaying the form with a transparent panel onto which I draw could be an alternative. But real transparency for controls seem to be a problem of its own in Windows ...
You can't do this easily without getting notifications from the app. Which, if it doesn't provide them, would require setting a global hook with SetWindowsHookEx() so you can see the WM_ERASEBKGND and WM_PAINT messages. That's hard to get right, you cannot write such a hook in managed code. Since it requires injecting a DLL into the target process.
The only other option is that you put a transparent overlay on top of your form. Another form that has its TransparencyKey property set. The basic code you need to get that right is available in my answer in this thread. You just need to tweak it so it is permanent.