I am currently programming my own interface with WinForms.
As the main application, a program runs on the main monitor (no touch), which should be controllable with the mouse and keyboard. The self-programmed interface runs on the second monitor (touch) and should only be operated with touch.
Now I would like to make settings with touch on the second monitor, but at the same time stay in the main application and work there with the mouse and keyboard.
There is also a connection between the two applications via lua and Visual Studio.
How can I change the WinForm so that I don't leave the main program when I touch it?
I would be very happy about a solution.
I tried with VirtualBox, but there I no longer have a connection between the main program and my application.
Related
On Pepper, 2.5.7.1, I'm using a .top dialog script as the main Interactive application to call other apps on the robot.
These work fine
[...] ^run(User/epicsax-6f83fc/behavior_1)
[...] ^run(User/taichidemo-c66a80/behavior_1)
[...] ^pCall(ALVolumeSlider.increaseVolume())
However if the application has to run something that is Interactive, the meditation application runs simultaneously:
u:(meditation) okay ^switchFocus(meditation-8806ca/behavior_1)
when this executes, the robot is still in dialog mode, eyes flashing blue and other still responding in accordance with the .top script.
I would expect that the first application would stop.
If I run this SSH command while the main dialog is running, I get the expected behavior where the dialog stops:
qicli call ALAutonomousLife.switchFocus meditation-8806ca/behavior_1
How is the .top file with these dialogue loaded? In collaborative dialogue, as a box in a behavior, dynamically loaded from script? If it's from a behavior, is that behavior also an Autonomous Life behavior? (i.e. with interactive tag, started with switch focus, etc.) If you started it with ALBehaviorManager.startBehavior then it won't automatically be stopped when you switch focus).
Some approaches:
Try ^pCall(ALAutonomousLife.switchFocus("meditation-8806ca/behavior_1")) - should be equivalent, but you never know
call qicli call ALDialog.getActivatedTopics so you can know if your topic is still running (it shouldn't be!)
I am helping a friend out with his new startup and he is looking into the possiblity of buying a server. A big part of the business involves running scripts to test various programs. The scripts automate mouse movement and clicks and keyboard inputs, basically mimicing a human user and logging how to program responds.
I understand that using virtualization, he could have one server running multiple instances of the operating system simulatnously. Unfortunately I don't have any experience with this.
What we would need to do is as follows:
Open an instance of remote desktop instance on the server through a laptop.
Run one of the automation scripts and watch the mouse move around the screen doing its work
Close the remote desktop on my laptop but leave the script running with the mouse moving around the virtual screen doing its work
Open 10 more instances of remote desktop to do the same thing
Login to each remote desktop a week later and check the progress
Basically if I close an instance of remote desktop, is there a way to keep the automated mouse movement script running?
Is there a limit to the number of instances that can be run at once?
I'd be greatful if someone could point me to some instructions on how this would work? As you could probably guess neither of us are IT experts! Thank you
I'm writing an application that will be run on a windows 7 system with a monitor and a front panel as a dual screen setup. Virtual desktop software will be used to access it most of the time, and the virtualization software should ONLY show what is on the monitor, not the front panel.
When set for "Extend these displays", the virtualization software shows both screens spliced together, and there does not appear to be a way to turn it off. If I set the Multiple Displays setting to be "Show Desktop Only On 1", the virtualization system works correctly, but now in my WPF application it's as if the second monitor does not exist. My Screen.AllScreens array only shows one monitor.
Is there a way I can get my WPF application to show on the second monitor in full screen mode when the desktop is set for "Show Desktop Only On 1"? For purposes of this application, it will ONLY ever be full screen.
You are approaching the problem from the wrong angle. You need to look at the virtual desktop software and not your app or Windows itself.
First off, for Windows to use dual screens, which you want, you must set "Extend these displays". Without this, it is impossible for Windows or any other software to use the second display.
Secondly, under "virtual desktop software" I assume something like Remote Desktop, TeamViewer or VNC. All of those programs should allow you to select whether to show all displays. For instance in Remote Desktop, before connecting you can select Options -> Display -> uncheck "Use all of my monitors for remote sessions".
If on the other hand you are looking for a way to limit the end user, that he/she couldn't in no way access or see the other monitor, then you must find a virtual desktop software that can only show the main display (this might be very hard, because most software can handle multi-display setups). The other solution is to extend your own software to stream it's main screen output to another machine and accept input from it - think of writing your own virtual desktop software.
I am testing my application (Windows 7, WinForms, Infragistics controls, C#, .Net 3.5).
I have two monitors and my application saves and restores forms' position on the first or second monitors. So I physically switched off second monitor and disabled it at Screen Resolution on the windows display settings form. I need to know it is possible for my application to restore windows positions (for those windows that were saved on the second monitor) to the first one.
I switched off second monitor and press Detect to apply hardware changes.
Then Windows switched OFF the first monitor for a few seconds to apply new settings. When the first monitor screen came back, my application became unresponsive. My application was launched in debug mode, so I tried to navigate via stack and threads (Visual Studio 2008), paused application, started and did not find any thing that help me to understand why my application is not responsive. Could somebody help my how to detect the source of issue.
Download the Debugging Tools For Windows then run adplus in hang mode. The with the resulting .dmp file open in windbg and invoke:
!analyze -v -hang
You should provide more information about what you saw in the call stack and threads windows. Which threads were running? Did you see anything that was waiting in a sleep or join? Have you tried naming your threads so that it's clearer as to what's going on when you pause (though not necessary since you can get this info from the call stack anyway... it's a convenience thing).
i have a WPF application that sits on top of all other windows. 99% of the time it works perfectly however if i dial into my computer from another location using remote desktop and then close the connection and go back to the original computer, my application is not visible. checking the running processes i can see that it is still running however its not visible at all. I assume it has something to do with the remoting but i was wondering if there is some code i can run say every 20 seconds that sits on its own thread that checks whether it is visible and if not will execute some code whether by pInvoke or .NET to become visible again. Any ideas?
Make sure to upgrade to .NET 3.5sp1. There were some changes with remoting which lead to WPF applications being sent as bitmaps in remote desktop in all situations.
In earlier versions of the framework, there were problems with WPF applications causing very odd behavior when combined with remote desktop.
Another idea - make sure you're using the latest and greatest versions of your graphics drivers from your graphics card vendor. WPF makes heavy use of DirectX, and this could potentially be a driver bug preventing the context from resetting appropriately.