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!)
Related
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.
I know what Ctrl+Z does. I should be also capable of not hitting it, but I do hit it accidentally and I would like it to work properly.
In Emacs, under Xwindows, Ctrl+Z minimizes the frame. It's handy. However... when I'm on windows using emacs over the network and using either Xming or VcXsrv the particular window in which I type Ctrl+Z will never work again.
That's right ... if I have several windows open, other windows are fine. In fact, if I hit the close window decoration, I get a popup window to save my file --- which works fine.
But ... when I bring back up the window in which I typed Ctrl+Z, I cannot move the cursor with a click, type anything. Even Ctrl+G.
So... How do I fix this?
(full environment for the curious:
win10 w/ Xming or VcXsrv
putty/sshd with X11 forwarding
FreeBSD 10 or 11 with emacs24
When running graphical emacs (using 25.1) from WSL Ubuntu connected to VcXsrv, I hit Ctrl-Z once in a while accidentally, because of muscle memory for "undoing". I experience similar freezes.
When this happens, as a workaround, try maximizing the window, and resetting the size to normal.
In my case, Ctrl-Z will minimize the app, but also partially freeze the GUI: the main buffer window doesn't seem to refresh, my mark/cursor disappears, I can't seem to be able to type new text, and the scrollbar won't respond. However, the emacs File, Edit, etc. toolbar options still seem to remain alive and respond to clicks.
I can get my window revived by maximizing the window, and resizing it normally. My cursor and visuals come back to normal after that.
In my App I have an annoying behavior. It is causing problems to my costumers.
The app has several points where I need to show a Dialog (Modal), then the users can fill some fields and then they can close the dialog. So the system follows its natural path.
In determined moments this works fine. The dialog is shown, user interacts with it, closes it , ....
But, in others moments (the same code) the dialog doesn't appear automatically. The user needs to execute some external action on device (like change its orientation, touch in the center of the screen, execute scroll gesture, etc). Some action that isn't intuitive at the moment.
This behavior makes the user think my app froze.
For me it is clear that the dialog was called, simply it wasn't drawed on the screen.
I tryed read about this problem.I did some researches in similar questions without success.
I guess the cause is related to EDT.
In short, How can I call a Dialog Modal without breaking EDT-rules.
And more specifically, How can I resolve this problem.
when I request a dialog to be displayed on the screen, I want it really appears in 100% of cases. Today works randomly.
Additional infomations:
My app uses Java 5 yet.
Do you recommends migration to Java 8?
======= Additional Informations (1) ===========
This problem is strongly dependent of device model.
In MotoG3 (Android 6) this problem is a exception. Rarely it occurs.
In my Galaxy Note 8 is the opposite. Always occurs.
In Lenovo Vibe5 (Android 6). Frequently occurs.
I added these informations. Maybe it help to compound problem picture.
Additional question:
Is it possible write a snippet that I can use as a template
to execute Dialog Modal call without break some rule of EDT?
Turn on the EDT violation detection tool in the simulator which should detect such issues. Inspect potentially problematic cases of Dialog calls and post them specifically if you don't know how to fix them.
Java 8 is unrelated although migrating a project is non-trivial.
I am developing a C program that prints out a message. The problem with it is that when I run its .exe file, it does not run in fullscreen (until I press alt+enter to force it to full screen). I want the program to run in fullscreen itself when I run it. Is there any way I can do it?
Thanks in advance.
You could call SetConsoleDisplayMode() to force CONSOLE_FULLSCREEN_MODE. Beware that support for this has been disappearing. The last machine I owned that could still do this has been gathering dust for quite a while already. Along with the memory of the loud relay clicking sound, mixed with the high-pitched wail of the flyback transformer in the CRT.
Edit: In addition to the bounty, we're willing to pay $250 to have this bug fixed in the Firefox/Gecko codebase. Here is a simple test project (Visual Studio 2008 C#) that reproduces the problem.
Edit #2 we're willing to pay $600 to have this bug fixed. See above for sample project that reproduces the problem.
We have a Firefox (Gecko) ActiveX control on our C# Windows Form to display HTML.
When this Firefox ActiveX control is on our form, about 2-3% of our key presses don't make it through. Or rather, a different Windows message is sent:
We hold down the TAB key to tab through 3 regular WinForms text boxes. It will behave correctly 97% of the time. Spy++ tells us WM_KEYDOWN message is sent properly:
normal behavior http://judahhimango.com/images/normaltab.jpg
But randomly, maybe 2-3% of the time, the tab key (or other key) isn't processed right. Spy++ tells us WM_CHAR is being sent instead:
odd behavior http://judahhimango.com/images/screwytab.png
When the odd behavior occurs, either the key is not processed at all, or is processed incorrectly (such as inserting a '\t' character into a textbox that doesn't support tab characters.
This only occurs if the Firefox ActiveX control is on our form.
Our question is: does Firefox/Gecko engine install some kind of keyboard hook that might cause these side effects? Or better yet, how do we fix this problem?
The WM_CHAR message is generated by TranslateMessage call, so a good place to start looking would be the TranslateMessage calls in the Gecko source code.
In the first example code you provided the function is imported only by two libraries - mozctl.dll and xul.dll. Since you claim that the same error happens also with GeckoFX we can take mozctl.dll out of the equation. That leaves us with xul.dll, so given the Gecko source code I would suggest to look into widget\src\windows\nsToolkit.cpp. I am not sure if the code is run if the engine is embedded, but if it is then the library starts a whole new message pump in different thread, which is bound to break.
Unfortunately I can't run or compile the code on my machine (Windows 7 x64 w/o the Mozilla ActiveX control installed), so I can't verify any of this with a debugger. Hope it helps someone to track it down further.
The root problem is that when Mozilla is embedded in another application, it incorrectly pumps Windows messages when it dispatches internal events. Mozilla uses an event system to coordinate across threads or to schedule deferred processing on a thread (see nsIThread, nsIEventTarget). If you embed a web page with a lot of active XMLHTTPRequests, for example, Mozilla will use its event dispatching interface to dispatch events back to javascript and it will pump windows messages as a side effect. Once Mozilla events are fully dispatched, it goes back to the main event loop.
When Mozilla pumps windows messages, it doesn't include the extra processing done by the application's event loop - IsDialogMessage(), TranslateMessage(), PreTranslateMessage(), or any other pre-processing are skipped when Mozilla gets into this state. Symptoms therefore include tab key presses getting inserted as a character instead of being used for dialog navigation, keyboard hotkeys being sporadically ignored, or custom message pre-processing being sporadically skipped. For example, the Outlook 2007/2010 "Compose" screen sporadically loses keystrokes because it relies on custom message pre-processing to handle keyboard input.
See https://bugzilla.mozilla.org/show_bug.cgi?id=582790 for a patch that addresses the problem.
I have Snoop Free and PSM Anti-Keylogger.
One of them detected firefox trying to install a Keyboard Hook.
Mozilla/Firefox file xul.dll attempt at installing at keyboard hook.
DENIED.
I noticed that you have implemented all of the interoperability yourself. Can you try this with the GeckoFX project and see if you get the same error? I use this project at work and haven't encountered any issues yet.