I'm working on a wxpython application that has a desktop GUI that allows users to place objects, connect them, move them around, etc. It has copy/paste and an undo/redo function (to reverse copy/paste and other actions).
If I copy/paste certain objects or perform tasks like connecting them then use undo it works fine. If I copy/paste other objects the undo event stops firing until I restart my IDE. (Using Wing). After the issue starts , pressing CTRL-Z, right clicking undo, nothing works, the event doesn't fire at all so I can't debug a specific action. Any suggestions on what might be causing this or where to look?
Related
I have a very large accounting system. In a user preferences section, the program has begun to act abnormally on my development machine only. No customers are reporting this, nor can I duplicate it on any of my other computers. Running Windows 8.1, others are on 7.0. Not exactly sure when this started happening because it's not the kind of thing one goes into on a regular basis. The preferences screen consists of a tab control and various standard controls. At the bottom is Okay, Cancel, and Apply buttons. All three buttons seem to be acting with the same strange behaviour. Clicking with a mouse does not generate a click event yet does not hang the system - mouseup follows and you can click it again and see the mousedown and mouseup but no click. However, since the Okay is defined as Default, pressing enter DOES create the desired click event, and all the code inside that even runs fine. Cancel and Okay also unload the form, but when clicked, that doesn't happen because none of the code gets executed, yet you can still navigate the screen (move between tabs and controls) but you can't even click the "X" button to close the form at that point.
Also, if you go straight in, and press enter, everything works and the form unloads, but if you do anything before pressing enter (or escape to cancel), like change a tab and/or edit a value, then press enter, the click event again does not run and the system semi-hangs.
I tried turning-off my anti-virus thinking that might have something to do with it, but no-go. Debugging is frustrating because while I finally got it execute the click event, the stop command inside that event (after debug.print "click") would allow stepping and success if just straight in and enter, but if anything else done as before described would stop at the stop statement (keyboard enter only still no mouse clicks under any scenario) and would do a total lock-out. In other lockouts where it would let me navigate, almost always selecting a new tab would cause a fatal error and it would force-unload VB for me, otherwise I had to use the task manager.
This is driving me nuts, but I don't know how else to debug it.
The culprit was tv_w32.dll which is Team Viewer. Turning-off Team Viewer allows my program to run normally.
I find myself working with GUI code where the GUI program needs input focus and remain the topmost window, but whenever I'm debugging with VS stepping-through with F5/F10/F11 requires that VS has focus.
Is it possible to have VS intercept the F-keys whilst the debugee has focus? If VS doesn't have this functionality I imagine it should be possible to write a simple program or VS add-in that has a keyboard book and commands the debugger accordingly - has anyone developed such a program?
I'm working with a GUI test automation framework that sends mouse-clicks and other events by moving the cursor. When the debugee program is out of focus any click on its surface brings the main window forward but does not activate any controls, but the automation framework assumes that its focus of the application will never be interrupted. So if I set a breakpoint before a click that is meant to open the File menu then the click that is sent will only restore the debugee's focus and not open the File menu (if that makes sense).
I've done some searching but couldn't find anything immediately.
Why do you need to maintain focus? Have you specific hooks in the GotFocus/LostFocus?
I've had problems before with the Paint event being called as soon as F5 was hit causing the debugger to show again and therefore requiring another repaint. I got around these simply by arranging my windows so they didn't overlap. I'm pretty sure the LostFocus/GotFocus pair also don't fire when the windows are arranged this way too.
I have a small utility app written in Visual Basic 6 that has been happily running on XP clients for many years until recently a client who is using Windows 7 has notified and shown me that the behaviour is different.
When my VB app displays the dialog, it remains hidden until the user clicks on it in the taskbar.
I changed the code so rather than using a ".show vbModal" command, I changed to displaying the form with non-modally, and then added various API calls like BringWindowToFront and SetWindowPos to make it top most AND calling .focus on the form, despite these extra instructions the best result I can achieve is to make the form flash prompting the user to click on it.
No matter what I've tried I cannot make the window display topmost, and with focus, without user intervention.
Note. this is an ActiveX exe project and is being called by a Win16 app through COM.
Has anyone else encountered this behaviour and know of a solution?
Any suggestions/advice appreciated, thanks.
Applications can't (without lying to Windows) steal focus. The calling app should really call AllowSetForegroundWindow() (if it's available on win16) to allow the COM process to steal the focus, or call SetForegroundWindow() itself.
See the help for SetForegroundWindow() for the conditions on setting focus.
I am trying to handle state restoration on a sub-page of my app. I've hooked the OnNavigatedFrom and OnNavigatedTo overrides in order to do this. However - although they fire quite happily while I am navigating around the app itself, the OnNavigatedTo does not fire when I switch out of the app with that page active, then try to reactivate it. This is made all the more mysterious because another near-identical app I have seems to work fine.
Is there some sort of setting somewhere that might prevent OnNavigatedTo from firing when my app comes back from tombstoning, but allows it to fire when the user navigates around screens in my app?
Chris
If you're going back almost immediately, it may be possible that your app is still running the same as it was, but the OnNavigatedTo should still be fired even in that case (more recent info: link text).
Are you doing anything fancy in your constructors, such as hooking up event handlers to try and handle the state changes from the frame?
If so, drop that and see where it gets you, ctors should be mostly empty.
I've been searching forever for a solution to this, so I thought I'd seek out the brainpower of greater minds than mine. I'm developing a Cocoa app that uses the Accessibility API to manipulate another program (it's a hotkey app). The app I'm controlling typically has multiple windows open, with some hidden behind others. What I would like to do, if it's possible, is to send mouse events to windows using the Accessibility API in a way that presses a button in the window without bringing it to the foreground (interact with the window but don't activate it). The reason I'm trying to do this is that sending the mouse event to this other window will force it to the foreground and disrupt the user's interaction with the foremost window.
This is possible on Windows - apparently, because apps similar to mine do it there - but I'm getting the feeling that this isn't possible with Cocoa, given the way the window manager works. Am I mistaken?
Accessibility is higher-level than that. You send, for example, AXPress actions to AXButton objects, but “press” is not necessarily a click—pressing the space bar while a view is focused, for example, is also a “press”. AXPress is a high-level action that means “do your thing”, which obviously has meaning for some views (such as buttons) and not others (such as fields).
Accessibility activating the application does make sense when you look at it from its intended purpose: Assistive devices for disabled users. If the user “presses” something by whatever means, they probably intend to activate the application and work in it.
Quartz Event Services will get you almost there: You can create an event tap for the process you want to control, and you can forge events and send them to a tap. The catch is that you can only send events to a tap when the tap fires—i.e., when the application already has an event to deal with. When it doesn't, you're stuck.