I need to copy the currently selected text from the currently active window in the currently active app.
If the app support guiInfo.hwndCaret, then I use this.
However, in some cases, the app does not support guiInfo.hwnd_Caret, and I have to fall back to plain copying to clipboard to get the currently selected text.
I am checking the WM_DRAWCLIPBOARD message to see when the content of the clipboard has changed.
However, when nothing is selected in the current active window, this message is not called because the clipboard has not changed.
How would I know that the Ctrl + C has been processed anyways?
Thank you!
From MSDN
Each time the contents of the clipboard change, a 32-bit value known
as the clipboard sequence number is incremented. A program can
retrieve the current clipboard sequence number by calling the
GetClipboardSequenceNumber function. By comparing the value returned
against a value returned by a previous call to
GetClipboardSequenceNumber, a program can determine whether the
clipboard contents have changed.
Related
It was easy when the Windows' explorer was using a SysListView32 control for displaying its files list as opposed to the DirectUIHWND control in the subsequent versions of Windows after XP.
A simple task such as obtaining the 'hot item' which is that item (a filename) the mouse hovers above for some hundreds of milliseconds, where before I could use the macros
ListView_GetHotItem with ListView_GetItemText and be able to obtain the filename under the mouse cursor.
This simple task becomes almost impossible to do with the DirectUIHWND window unless I revert this control back to a
SysListView32 which I have seen being proposed as the only solution on the many sites I have searched, and even if used the change does not occur immediately but only after I navigate out of the folder first.
It has taken me almost 2 years trying to find a solution to this and until now I feel stumped.
Anyone any idea please ?
Basically I have subclassed the parent of the tooltip and intercepted the tooltip notifications and all I need is the filename and the full path of the item the mouse hoovers above it, the hot item.
https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/march/windows-2000-ui-innovations-enhance-your-user-s-experience-with-new-infotip-and-icon-overlay-shell-extensions
IQueryInfo is required to provide the runtime text to the shell. IPersistFile is used by Explorer to let the extension know about the specific file currently under the mouse pointer.
I am trying to view the entire contents of a variable in the IDLE Debugger for Python 3.6.1. The debugger gives a preview but there appears to be no way to pull all the data out from the debugger.
The only work-around I've found is to throw a print() statement in the code somewhere. Is this the only way? See picture:
This example's decryptedText variable has over 700 characters but as we see, only a few are visible. Thanks.
As the IDLE debugger is currently written, the only way to get more information about the state of an object at a particular point in the execution is to either insert print calls in the code or stop execution (raise SystemExit, for instance) and interact with the object in the Shell.
What you see in the locals/globals panels are representations of objects produced by reprlib.Repr with maxstring and maxother increased to 60. One could edit NamespaceViewer in idlelib/debugger.py (3.6 name) to increase maxstring to, say, 200 and maximize the debug window. (I verified that this works to show more of a string.) One could also try replacing the single line Entry widget with a Label widget sized to height lines and width chars and setting maxstring to height * width. (Untried.)
I agree that being able to get more information on a object would be good. I am currently thinking about a separate popup window with type, length (if appropriate), and a much bigger slice of the contents.
I'm wondering if it is possible to output text to the main window in foxpro while a form is active? Once the form is up my ? commands get sent to the form but that is not where I want them displayed.
Look into the command
ACTIVATE SCREEN
This should redirect to the main VFP window and not the window you are currently in. I know, it's a pain with these '?' outputs that keep shifting up the visual content within whatever is the current window.
You need to set the AllowOutput property of your form to false.
Setting the AllowOutput property to False (.F.) on a form, changes the following Visual FoxPro behavior.
Painting of the form is redirected to the next output window or desktop. This affects commands, such as ?, ??, DIR, LIST, DISPLAY, CLEAR, and other commands that display output on a form.
The WOUTPUT( ) function does not return the name of the active form. It returns the name of the current output form or desktop.
The BROWSE command does not inherit the window size and window settings of the form.
The MCOL( ) and MROW( ) functions, without the use of their optional parameter, may not be relative to the form they are called on.
I don't do much programming in applescript but I have a personal app which is mostly python but generates simple applescripts and calls them via a system call. Applescript is so different from the languages I usually program in that I can't figure out how I...
get the window order of a document within an application?
For making calls like:
set bounds of **first** window to %s
in other words, how can I get the document's "window order" for an application?
Is it possible to interact with a window through accessing the document like this:
to get bounds of first window whose document is "%s"
(which doesn't work) or do I have to get the document's window order first and then interact with that window (via its order) in a second line?
Any insight would be great. Thanks.
You can do both of these things just fine. The first line is just set bounds of window 1 to ..., or, if you prefer, set bounds of the first window to ... The second one depends on what, exactly, you want to do. If you want to access the first window whose name is something in particular, you can just do get the bounds of window "NAME"; if you really want the name of the document, though, you'll need to do something like
set d to the document "NAME"
repeat with w in windows
if w's document is d then return bounds of w
end repeat
You should be able to do the first window whose document is d, but this fails; as far as I can tell, it's because document is also a type name. Also, if window "NAME"/document "NAME" fails—it's the sort of thing that I remember sometimes not working, even though it should—you can instead use the first window whose name is "NAME" (or the first document ...). But the simple form will almost certainly work.
Also, if you're just generating these AppleScripts, calling them, and deleting them—in other words, if you're pretending they're Python functions, rather than generating them for later use—I'd highly recommend using appscript instead,. I've never used in in Python, but I have in Ruby, and it's a really great way to deal with everything AppleScript does while still using your language of choice. For instance, I think your first example would become app('Whatever').windows[1].bounds.set((0,0,0,0)), (or ...windows.first.... if you prefer) and your second would become either app('Whatever').windows['NAME'].bounds.get() or app('Whatever').windows[its.document.name == 'NAME'].get(), depending on if you need the window's name or the window's document's name. This is all untested, but certainly captures the flavor of what appscript tends to look like (nice and concise).
I'm using the Cocoa Accessibility API to try and modify the value of a text field (AXTextField) in another application, but I've run into a problem: my code correctly identifies and modifies the contents of the text field in question, and the text of the field visibly changes, but the changes aren't registered by the program I'm trying to control. Is there a way to do this in with the API without having to generate keyboard events?
Sample code:
AXUIElementCopyElementAtPosition(appRef,
clickPoint.x,
clickPoint.y,
&boxRef);
NSString *valueToSet = [NSString stringWithFormat:#"%f",amount];
AXUIElementSetAttributeValue(boxRef,kAXValueAttribute,valueToSet);
And the text field changes to the value specified in "amount" but the other program doesn't recognize the change - I have to go type the number in myself to get it to pick up the change (I can tell the difference, because the program responds when a new value is typed in the box). Can anyone point me in the right direction?
For posterity: Informed sources tell me that this is actually a bug in the application I'm trying to control. You can tell the difference by using UI Browser (http://prefabsoftware.com/uibrowser/) to try and set the value of the textfield; if UI Browser can't make the change stick, then the matter is out of your control.
Try telling the text field:
perform action "AXConfirm"
This is Applescript, but whatever the Cocoa equivalent is, it may make the change stick even if UI Browser can not (I've used it before).