I took over a Keyboard hook project and have been sprucing it up a bit. It used to be just 4 forms that had all the logic and maths in those 4 files. So MANY hours later I just about got the program back together after decoupling everything. The latest bit is by using the Model-View-Presenter design concept on the main window. All my tests work great on my machine, and naturally the program performs like it should on the target computers.
The target computers are simple x86 Intel Atom processors with 2gb of ram. They have buttons on them that correlate to F13-F18 on a keyboard (that is where my keyboard hook program comes into play). My development PC is a semi-stout 6-core AMD x64 machine with 8gb of ram. One thing I wanted to do was test out a way of setting those Function buttons to a particular task. All my unit tests pass for this portion. When I click on a new task type it works as desired.
"Cool", I say, "Lets see it in action" so i hit run in Visual Studio. I my program that F9-F12 are the keys to hook. Now the assignment window only opens up when you press one of the hooked keys when the main window is open. If that main window is not open then the task is performed. So I open my main window and hit F9 and the Assignment window shows but i can't click on anything for about 4 seconds. Then it "catches" up and does what ever I clicked on. I thought maybe it was my debugger so i went to the bin folder and ran the application directly and same deal.
I thought maybe it was a permissions thing so I ran as admin and same problem. I wondered how bad it would be on the target computers. I copied my bin folder to a flash drive, copied the content into Program Files and ran it. It worked great (well to a certain degree) But the problem was not present. I can select any task I want immediatly after the dialog is visible.
One strange thing is though that my keyboard hook stops working after 11 times of trying to reassign it...but that is a separate question. So i thought I remember someone saying, use a profiler. Well my visual studio had one so I turned it on but i can't make heads or tails of the data returned. I'd post code, but I don't know what to post. I even went as far as using System.Console.Write("."); around the area I thought was the problem but that wasn't the problem
protected override void theHook_RegisteredKeyPressed(System.Windows.Forms.Keys key)
{
if (TakeOver)
{
if (!Busy)
{
busy = true;
LibraryTrace.Start("NewKeyAssignment", key);
using (var window = new AssignmentTypePanel())
{
presenter = new TaskPresenter(window, theList[key].Task);
window.Presenter = presenter;
//execution will not continue past here until window is closed
window.ShowDialog();
}
theList[key] = new TaskKey(key, presenter.Task);
LibraryTrace.End("NewKeyAssignment", theList[key].Task.ToString());
busy = false;
}
}
else
{
base.theHook_RegisteredKeyPressed(key);
}
}
So i'm stuck. I can't figure out what to type, what to ask. Any tips on how i can find the root of this problem?
I had a similar problem with an application i developed using winforms- the 'server-side' operation was lightning-quick, but still the form showing the results took ~5 seconds to show.
Upon investigation, it turns out that winforms has some known performance issues.
There are some suggestions for optimization (like here or here and a few others i've found at the time but can't seem to locate right now).
Actually, none of them helped in my case.
I ended up realizing that the real bottleneck was creating and displaying a new form; what I ended up doing was a bit of a hack-
I placed ALL of my controls on the main form, with some of them hidden, and simulated a change of forms by hiding some controls and displaying others.
It's quite ugly, and won't scale up, but worked very well in my case.
Related
I haven't been able to find someone else who has this same issue and it is extremely frustrating. Basically, for whatever reason, Coded UI is seeing a control in a different area then where it actually is. Like this:
Bounding Rectangle for Label with "IDLE" in it is up and to the left of the control
As you can see in the picture for some reason the Bounding Rectangle is up and to the left of the selected Label with the word "IDLE" in it. This is the first time I have seen this issue and after doing like 50 googles searches I decided to come here.
First off I am using Coded UI with a Windows Forms Application (I don't know if that makes a difference), it seems to do the same thing with all Windows Forms Applications, it has worked fine for all my WPF applications.
Second, no matter how many times I record my click on a button in my application or something of the sort, running the recorded method will always click off the button (due to it thinking the button is positioned up and to the left of the control). Up and to the left seems to be the only consistent thing, how much up and to the left varies based off of where the application is on the screen.
If anyone has any ideas or something I can try please help, I have no idea what is going on. If you need anymore information feel free to ask.
Thanks
Edit for Code sample:
public class Controller : WinWindow
{
#region Constructors
public Controller()
{
SearchProperties[PropertyNames.Name] = "My Sample C#";
SearchProperties.Add(new PropertyExpression(PropertyNames.ClassName, "WindowsForms10.Window", PropertyExpressionOperator.Contains));
WindowTitles.Add("My Sample C#");
enableWindow = new EnableWindow(this);
}
#endregion
public WinEdit CommunicationSetup
{
get
{
if(communicationSetup == null)
{
communicationSetup = new WinEdit(this);
communicationSetup.SearchProperties[PropertyNames.ControlName] = "Communication";
communicationSetup.WindowTitles.Add("My Sample C#");
}
return communicationSetup;
}
}
private WinEdit communicationSetup;
}
Extra Edit:
To Click on the thing I've used this:
Mouse.Click(new Point(obj.BoundingRectangle.Location.X + 20, obj.BoundingRectangle.Location.Y + 10));
and This:
Mouse.Click(obj);
Both click up and to the left of the control, as expected since the BoundingRectangle show there as seen in the picture
Edit: To replace "right" with "left" because I'm clearly an idiot and don't know my directions lol
Edit: Here is some more pictures showing the DrawHighlight() for the button Enable on my application, sorry I have to take a ton of information out for company policy reasons which might make it a little difficult to see what everything is going on but I have to
I also moved the application around so you can see how much of a difference DrawHighlight() has when the application is moved
Application dragged further down and to the right
what is stored in the obj variable that you try to pass to Click() method?
The problem might occur because you have not enough unique properties, who may definitely describe the control. Try to add additional SearchProperties. The most valuable would be a Control ID or Automation ID. If you cannot obtain this property on the wanted control, ask your development team to add it.
Try also to debug the method. Investigate of is returned in BoundingRectangle property of the control. Try out DrawHighlight() method. It will mark the position of the control with a blue rectangle. Another option would be to use TryGetClickablePoint() method. Maybe your control's size is bigger than you can visually obtain. The last but not least: examine your control from UIMap Editor and its whole hierarchy. You might find that the control you are looking for was badly recorded.
If nothing helps, then provide some more information and results of your investigation.
Good luck with that one.
Alex
I figured a consistent way to solve my problem, thanks to #Loathing for his comments on my question. Here is how I solved it:
var ret=new Rectangle();
GetWindowRect(obj.WindowHandle, ref ret);
Mouse.Hover(new Point(ret.X, ret.Y));
I still am not sure why this works so if someone sees this and understands feel free to comment and explain, I'm a little fuzzy on what goes on with GetWindowRect.
I recently came across some interesting results when trying to debug cross browser tests between IE and chrome that similarly mimicked what you've reported. It turns out that CodedUI and IE seems to be sensitive to the display scaling. I was using a multi monitor setup with different resolutions and changing each's scaling, using mostly 125%. The control's top and left coordinates were always off in IE and I could never figure out why. After doing some math and dividing by 125%, sure enough the number matched the coordinates it was supposed to be reporting. If I tried to change the monitor scaling without restarting windows, the issue got worse and I would also miss clicks. I imagine your solution to GetWindowRect appears be DPI sensitive as well, and reporting the correct coordinates with scaling taken into account.
Link to microsoft page that loosely discusses this:
Understanding Screen Scaling Issues
I get this all the time and the only way I managed to resolve it is restarting windows (go figure yet another MS solutions with Restart of the entire OS). Anyhow, in my case, it could be working fine, but later I would RD into my desktop from a laptop and everything would go nuts with this issue. I had to restart when working directly with PC and restart again when working from RD session.
I have had this issue fairly frequently as well. In my case whenever my code tried to download a file, the browser would popup the little download bar at the bottom. From then on, all my location rectangles would be off by the height of that bar.
My guess is that it is a bug in Microsoft's CodedUI that is unable to reset itself when the window it is testing changes sizes in certain cases. I have found a lot of bugs in CodedUI, I really hope that some day they get it more stable.
The fix for my issues so far has been to close the Internet Explorer window I was using to run the tests and restart it. CodedUI can't even get this right though, so I go out and kill all iexplorer.exe processes then re-start the browser.
I'm writing my first Windows Store app (windows 8.1) and I notice that when I run it in debug mode, and I close the app (by clicking the x in the top right, or by dragging from the top of the screen to the bottom), it is still running in Visual Studio. My first question is, is this a problem? It seems like it's a problem.
I started from a template, I'm not doing anything with threads, and there is only one page (MainPage.xaml) at the moment. I have looked at questions which seem similar, in particular this one:
WPF App Doesn't Shut Down When Closing Main Window
but I am unable to get their suggestions to work.
When I add ShutdownMode="OnExplicitShutdown" to my app.xaml, I get these errors in my Error List:
The member "ShutdownMode" is not recognized or is not accessible.
The property 'ShutdownMode' was not found in type 'Application'.
Also I notice that there is no StartupUri specified, nor can I add one (same errors as above.)
The other suggestion was to override OnClosed in MainWindow.xaml.cs and close the application there. I have no MainWindow.xaml.cs; I have MainPage.xaml.cs instead, and it does not have an OnClosed.
The Application class is of type Windows.UI.Xaml.Application.
If I pause VS after closing the app, it takes me to this (generated) code:
#if !DISABLE_XAML_GENERATED_MAIN
public static class Program
{
[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Windows.UI.Xaml.Build.Tasks"," 4.0.0.0")]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
static void Main(string[] args)
{
global::Windows.UI.Xaml.Application.Start((p) => new App()); //<==here
}
}
#endif
Can anyone tell me what's going on?
This is entirely normal, the debugger tells you what is really going on. All Modern UI apps work this way. Just check it out with Task Manager, Details tab. Observe how dismissing the window doesn't terminate the process, it just suspends it.
You don't just have a modern UI, you have modern operating system behavior as well. A user doesn't have enough information available to judge if terminating a process is actually useful. If the machine has plenty of resources then there isn't any point. Better to keep the process running so that when the user starts it again, it instantly wakes up. Which is nice, users like that.
Conversely, if the OS requires resources for another process and not enough are available than it will automatically terminate a process without the user's assistance. The life-cycle for Modern UI apps supports this. Nothing particularly revolutionary btw, mobile operating systems like Android do this as well. Also the way I use my desktop apps these days, I just leave them running. Until I run out of taskbar space, cleanup then. Annoying :)
Truly stopping the process is easy, just click the Red Button on the VS toolbar.
I’m developing a screen saver in C# .NET4.0 on VS2010 which needs to do a fair bit of processing before it actually shows screens (fairly complex database access). This is fine because the user is unaware that this processing is going on and then the full screen forms kick in when everything is ready. That is, unless we are running on Windows 8.
Searching on the Microsoft Community (http://answers.microsoft.com/en-us/windows/forum/windows_8-desktop/bubbles-screensaver-has-black-background/e0807324-5ca6-4abe-b6ba-716848b41ff5?page=4) reveals that a design change was made in Windows 8 that prevents screensavers from drawing over an image of the desktop. Any screensaver that previously drew over the desktop will instead draw over a plain background using your chosen “metro” background colour. Experimenting reveals that this background kicks in immediately the .scr file launches i.e. before any forms can be displayed. Hence tricks like displaying forms minimised or with 0% opacity don’t work because this simply reveals the plain background underneath.
The best I’ve been able to come up with is to display full screen plain black forms as first action when my code starts i.e. before any database processing or other screen construction takes place. Why try to replace a plain screen with another plain screen? Well, because the default Windows background colour seems to be blue. That’s blue as in BSOD blue which looks kind of alarming when it kicks in. So the best I can do for a Windows 8 user experience is a quick flicker of blue followed by 3-4 seconds of plain black before screens are populated with something meaningful.
This new behaviour from Microsoft is apparently “by design”. The fact that it doesn’t manifest itself in Preview mode is apparently an error which one supposes MS will tidy up later.
So my question is does anyone know any way around this so that I can continue to have the desktop showing until screensaver forms are ready to kick in?
I struggled quite a lot with a similar problem regarding this awkward design decision in win8.
I the end had to compromise but my search continues for a a bullet proof solution, when I have time.
Now what I ended up with is running a batch file after the monitoring system starts and have thread detect idle time and run that batch again.
#start /wait Bubbles.scr /s & rundll32 user32.dll,LockWorkStation
What this does is:
starts screensaver preview in fullscreen (this works in win8) and waits
on user action lock screen is show and user prompted for password
As I said it's a compromise until a find something better. Hope it helps
Updated to win10; try to use that cool scr and found same issue;
Try to trick ms restriction and found only one very long solution:
enable logging of screensaver invoked events;
here instruction via gpedit: https://superuser.com/questions/538146/run-a-batch-cmd-upon-screensaver
now you will able to start other comand or app when screensaver starting;
goto C:\Windows\System32
copy Bubbles.scr and rename to Bubbles.exe
then config task to run C:\Windows\System32\Bubbles.exe with argument /s (administration->taskcheduler)
use some windows screensaver and config to use 1 min or more; (or use 'runsarver' with empty options from upper link or create your own empty.exe and rename to .scr and install with right menu, etc)
Found cool app to customize hidden screensaver features: http://winaero.com/download.php?view.8
(work with small bugs but work as needed under win10)
All work fine one cons checkbox to lock PC must be unchecked;
If needed create own app to run Bubbles and on exit lock PC or bat file as above, etc;
hope people will have fun with my solution :)
We are building a WinForms based app (using .NET 3.5)
Recently i have encountered that when performing one of our application's main workflows, the application will become unresponsive in a matter of seconds, failing to properly render the UI (Shows the "Program is not responding" message).
We have reduced the issue to a suspected line of code that adds a tooltip to a label control:
ToolTip tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
I have spent the past 2 days figuring out what in this code could code any issues with the UI thread, but failed to do so.
My question is -- is it possible to use a performance profiler to gather information about code such as this? Note that the ToolTip class belongs to WinForms and i do not have the source code available for it.
Removing these lines seems to solve the issue completely.
I would like to reduce debugging efforts in the future, as this issue can manifest in other locations of our codebase.
EDIT:
The only similar reported issue i could find was this: WinForm ToolTip.SetToolTip is Hanging my application :(
You could use a program such as JetBrains DotTrace to see what is happening that actually causes the program to halt
I have the same problem, except I use a ToolTip object placed using the designer and then in the Popup event of the ToolTip I set the text for the ToolTip.
The problem only occurs on Windows 7 64-bit (I don't have a possibility to test 32-bit Win7), on 32-bit Windows XP, this works fine.
edit: i guess there was some recurrent calling of the popup event, because when i moved the tolltip setting to other place of my code, it works OK.
I know that this is an old question, but the hanging still happens on Windows 10 64-bit edition. On Windows 10 32-bit everything works fine. I have not looked at the .NET source code, but it must be a wait or something. So to overcome this problem I added the following workaround:
this.Invoke(new Action(() =>
{
tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
}
));
I was already calling this from the main thread, so according to MSDN documentation this doesn't make sense, but it releases the wait lock or something.
There is a program where I work that works fine when running the .exe file but works differently from expected when opened in VS2005 and played from there. I am therefore asking on here if anyone knows of anything that would work in the .exe file but not the debug from VS? I am not able to post the code for the buttons I'm talking about but I'll try to explain the best I can.
There is a receiver hooked up to the computer. When the button is pressed on the program, it shows a message and waits for a signal to be received. After the signal is heard the first message box is supposed to close and another is supposed to open. When using the .exe file this happens just fine. However when playing from the program from VS2005 (the same one from which the .exe was made) the second message doesn't come up when it is supposed to and when I can make it come up, the first box doesn't close. There is also a timer involved if that helps.
Also, is there a fundamental difference between how the two operate when executing the program?
If I need to make anything more clear or give more details please let me know.
Running a program under the supervision of a debugger can change the timing of events compared to running the program standalone. The debugger slows things down. Normally, this doesn't make any difference to the operation of the program, but if you have code that is dependent on the "coincidental" rapid timing of some activity, that happy coincidence may be broken when things slow down under debugger control.
The debugger can also cause changes in focus and activation depending on where you set your breakpoints - generally not a good idea to set a breakpoint in focus change or activation events because stopping at the breakpoint will change focus to the debugger, away from your app. But these are interaction issues. Just running your program under the debugger with no breakpoints shouldn't affect focus or activation in your app.
Review your code carefully. Consider what could happen to your program flow if you inserted delays between every source code statement. If that could lead to problems, you have a design bug that needs to be fixed. Reliance on coincidental timings will lead to bug reports and support calls, particularly if your customers have slower hardware than your development machine.
When you run under the debugger, or even in the VS testing host, there are some subtle differences. This shouldn't effect your program under normal circumstances, however, since most of the differences are similar to running (the debug version) of your application on a slower system.
Given your descriptions, I suspect that your problem is actually due to calling to the UI from a different thread than the control was constructed with. Make sure to always marshal any calls to the UI using Control.Invoke or Control.BeginInvoke.
It may be an issue with the Host Process, disabling it is a painless click and just as easy to re-enable. It may be worth giving a try.
Disable Host Process
I know this can effect Direct X and other API but I've never had exactly the situation you are in so I make no promise.