How to grab the scrolling amount in one window? - scroll

This is the first step to scroll two windows simulteneously, the second step is to find a way to apply that amount to the other program. But I really don't know where to start, all I see in from Google is about modifying the behavior of the scroll of the mouse, not the scrolling amount in one window. Advantages of using this instead of listening to the keys:
Scrolling will be seamless since the other program are scrolled in the background
Clicking on the scrollbar works
Different scrolling speeds don't affect the comparison
Moving lines in text editors won't scroll pages in PDF viewers

I can tell you what I would do, but it's not going to be fun...
Assuming the text is roughly evenly distributed (which it might not be between two languages like that, and two windows with different text sizes and widths, really consider this carefully before you do the work), then the goal is to force both scroll bars to be at the same percent relative to their whole. So what you need to do is write a function to determine what percent each scroll bar is at. I would screen capture both windows and crop out the important parts of the scroll bar like this:
Specifically the up and down buttons, the top of the scroll handle, the bottom of the scroll handle. Save them in their own files. Do it for both windows in case they draw their scroll bars a little differently.
Now the tricky part. Write a function that does the following: imagesearch for the top button within rightmost 25 pixels or of the specified window. Same for the bottom button. Same for the top of the handle. Same for the bottom of the handle. Use this to determine where your window is.
SetTitleMatchMode, 2 ; so it matches the end of the title
WinGetPos , X, Y, Width, Height, LibreOffice Writer ;exact substring of window name required
Use something like this to find the scroll bar parts.
CoordMode, Pixel , Screen ;so image search searches entire screen
barwidth = 25 ; make sure it's more than the bar is wide.
ImageSearch, TopButtonX, TopButtonY, X+Width-barwidth , Y, X+Width, Y+Height, TopButton.bmp ; no jpg, fuzzy edges make searches fail
Then do some math, something like:
TopButtonY := TopButtonY+TopButtonImageHeight ; because we only care about the position of the bottom of the button.
BottomHandleY := BottomHandleY+BottomHandleImageHeight ; because we only care about where the bottom of the handle is.
HandleHeight := TopHandleY - BottomHandleY ; how tall the scroll handle is
TotalHeight := TopButtonY - BottomButtonY - HandleHeight ;how tall the scroll field is
HandleOffset := TopHandleY - TopButtonY ;how far it is from the top
HandlePercent := HandleOffset / TotalHeight ; the part we care about. return this value
With a function like that, you can know how scrolled each window is. All that's left is to send the scroll commands. There's a few choices.
; ControlSend , Control, Keys, LibreOffice Writer
ControlSend , Control, {Pgdown}, LibreOffice Writer ; or {Pgup}
ControlSend , Control, {WheelUp}, LibreOffice Writer ; or {wheeldown}
ControlSend , Control, {Up}, LibreOffice Writer ; or {down}
If it lets you move the caret with up/down arrows while the window is inactive, that is probably the most precise option, even if it takes a bit longer. The fastest most precise way is to simulate a click drag also using control send. To use ControlSend you need to figure out which control you're working on. WindowSpy can help you with that.
So first: Find the scroll positions of both windows. Second determine which window is active. Third, nudge the inactive window in the correct direction. Repeat until they're within a certain tolerance range (otherwise it will bounce up and down endlessly).
I can't emphasize this enough, but please make sure that getting the scroll bars in approximately the same positions is sufficiently close before even attempting this. If it isn't, you will have wasted a lot of time fiddling with it. Keep in mind it will be less and less accurate the longer the text is.
If it is an option, I would definitely consider copying the contents of both windows into a program that gives you more access to the controls (or better one that is specialized for this purpose). If you had more access, you could use the paragraph breaks to line up the texts with far more precision.
If you really just want to see both texts side by side (and the paragraphs do line up), you could find a text editor that tells you information like this:
If autohotkey will let you read the text of that information, you can copy the PDF into autohotkey's memory (separated by line) and use autohotkey to show only the corresponding paragraph of the PDF as you move around in the editable document.
Hope something I said helps, good luck.

Related

Detect file drag & drop to the right/left of the desktop

For a small demonstration application, I want the option to delete file (from the files explorer on windows) by simple dragging it all the way to left/right side of the screen (the all desktop, not the application)
Is there a way to do it?
Thanks.
For demonstration purposes you could create a borderless always on top window that fills the entire screen and cut out a hole in the middle of it with a window region so you are left with just a 1 or 2 pixel wide strip on each side and set the opacity to 1 so it is basically invisible. You could then handle drops on the window.
On Windows 8 you might run into issues because it already uses the edges.
I don't believe this feature is useful enough to actually implement as a real product though.

Windows API Functions in FORTRAN - What series of API's is needed to Simulate a Window MAXimise button action?

first off, I'm very new to using API's so please bear with me I'm on a steep learning curve !
I'm creating an application using Silverfrost Fortran FTN95.
I've been trying to initiate the opening of an initial Window within the program which uses the whole screen
useable area (the so-called WORKAREA in API parlance) but am having a problem.
Having used GET_WINDOW_LOCATION# API function within my Fortran code to obtain the dimensions and origin of the max possible area for
the window (without taskbar), I've then defined the 'origin' of the window to be at -n,-n where the border is n pixels thick and I've
increased the window dimensions by (2xn) in each direction so that the other 2 borders will be off-screen at top or under the taskbar at the bottom edge).
Anyway, I'm having difficulty obtaining exactly the same as produced via clicking the 'MAXimise button' on a window.
While the window produced itself seems to occupy the whole area available, when it appears the CAption appears right on the upper edge of the
CAption ba(i.e. not centre justified vertically).
Also, the MINimise, MAXimise and CLOSE buttons in top rh corner of window do not fill the whole depth of the CAption bar (they're about half the depth and indeed appear to be cut-off).
If I subsequently click the window 'MAXimise button' after initial window creation then the CAption and buttons re-align themselves correctly.
This is all illustrated in this image here:-
http://s1164.photobucket.com/user/john_pbucket/media/SilverfrostForumsImageFiles/MAXWIN-Summary_zpscajfx3vx.png.html
Note - I first created the full window with borders within the available screen area (this is the first example shown) where the window Border (8pix wide) is visible
The subsequent attempt to create the window as per the MAXimise button places the window at origin (-8,-8) and I increase the window dimensions by 16 (2xborder width) in each direction in order to get the borders off-screen, but thy're still there.
So, What series of Windows API commands should I be using exactly to get the window to open in a correctly maximised state, and are there any 'subtleties' of alignment and/or spacings I should be aware of which may be causing this problem?
I guess the question boils down to 'what sequence of API commands does the window MAXIMISE button execute ?' but I can't find an answer anywhere.
Maybe there are also some subtleties I need to know about with regard to any windows dimensions parameters which could be creating the anomaly ?
Any help/guidance would be appreciated. Thanks

Programmatically find blink cursor position in windows c++?

How to find out blink cursor position in windows, from c++? In many cases I need send button click on the position of the blinking cursor, but I didn't find any important function which will take care of that.
OS win 7(64), c++
It is called "caret", cursor is the mouse pointer. You use GetCaretPos() to get its position. But the returned position is relative to the client area of the window that owns the caret. Which probably means that you need to find that window first, use GetForegroundWindow() for that. And don't send button click messages, they are posted so use PostMessage().
Avoid all of this by just using SendInput().
Note that UIPI (the user interface component of UAC) prevents you from poking stuff into a window owned by an elevated process.
GetGUIThreadInfo() is probably your best bet; pass it with idThread = 0 to get the info from the currently active thread, and then check the rcCaret member of the returned GUITHREADINFO structure. You'll then need to use ClientToScreen() with the hwndCaret value to convert client-relative coordinates to screen coordinates.
Note that this only works for apps that use the Win32 caret functions - specifically SetCaretPos(). If an app draws its own caret without using these, you may not get anything meaningful back. (Some apps, like Word, draw their own caret, but still call SetCaretPos so that accessibility aids that need to track the caret can use this technique.)
The rectangle you get back can sometimes be wider than the actual caret. When a bitmap is used for the caret, as is the case for Right-To-Left or Left-To-Right carets that have a little 'flag' attached to the top, you'll get back a rectangle that's a bit wider than the actual caret area, and may need to adjust or otherwise figure out where within this area the actual caret bar is - it may or may not be in the exact middle. Looks like for Notepad++ you should be fine, though.

Cool user interface alternatives and improvements for Scroll Bars

Scroll bars are really boring. I've seen a few really inventive new user interfaces for updating these. I believe there are many better ways to spend 10px then with a solid color and static buttons. Here are two examples I've found:
http://www.youtube.com/watch?v=-PnXY4wjuH8
http://chikuyonok.ru/u/demo/infoscroller/
(credit for this link goes to this question uses HTML5 Canvas )
Do you have any other ideas to add to this list? How can we give a better idea of view-status in the document, without wasting so much real estate? How can we add more functionality to the notorious dead space on the right?
Firstly, one should be very careful about “updating” the scrollbar. The scrollbar is a great success story, a simple, elegant, powerful control that is critical for successful computer use and almost universally understood by users. Trying to improve the scrollbar is like trying to improve the ballpoint pen. It’s stayed the same for so long because there’s really not much more you can do. Being "boring" is not a good reason to improve it. Users don’t use an app or site because it has new and "cool" controls. They use an app or site because it lets them accomplish their tasks. To improve the scrollbar, consider how changes can improve task completion.
Good things the humble scrollbar has:
Capacity to scroll one pane-full.
Capacity to scroll one line (fine tuning).
The capacity to do each of the above repeatedly without moving the mouse (so a user reading some content only has to click occasionally after initially placing the mouse over the right spot).
Allows random access to anywhere in the pane by simple linear drag and drop.
Intuitively shows the relative position in the content (e.g., allowing the user to judge how close s/he is to the end).
Intuitively shows the relative size of content by the size of the slider relative to the track.
Supports intuitive keyboard activation via the cursor keys -good shortcuts, and good for accessibility.
Supports clickamatic (pressing down and holding the mouse button to scroll multiple lines or pane-fulls).
Very smooth real-time feedback on user actions.
All in a remarkable compact and unobtrusive control that doesn’t distract from the content (what the user is really interested in).
You don’t want to mess with any of that. In particular, the pop-up scrollbar you link to is probably a bad idea because it interferes with the capacity to scroll by a pane-full by clicking the track. That is perhaps the most common user action so it deserves the greatest number of pixels (i.e., the track).
On the other hand, building on existing scrollbar capability, like the Infoscroller you link to, is a something worth investigating further. For the original research on this concept, see:
McCrickard DS and Catrambone R (1999)
Beyond the scrollbar: An evolution and
evaluation of alternative navigation
techniques. Georgia Institute of
Technology Technical Report
GIT-GVU-97-19.
Obviously, what you show in the scrollbar track depends on your content. A thumbnail of the content won’t work well for a text table or list. For that, Greg Raiz has suggested indicating the values for the current sort order. If there’s not enough space, maybe tooltips or callouts can appear pointing to key places in the track to drag to. MS Word does something similar with this, showing a tooltip indicating the page and section of the current drag-to point.
Here’re some other ways we could build on the scrollbar:
More Buttons. I’ve seen suggestions to include both up and down buttons at the top and bottom so the user can transition between scrolling down and up without having to slew the entire height of the pane. Or you could have buttons to scroll immediately to the beginning and end of the content, handy for users who don’t know about Ctrl-Home and Ctrl-End, saving them from making a long drag of the slider. MS Word includes buttons to execute the last Find or Goto, among other possibilities.
Split bar. On the subject of MS Word, MS Word and Excel scrollbars include a split control to allow you to divide the window into two panes. That would be handy for a lot of other applications, such as browsers and large lists and tables.
Expert activation. If you don’t want to clutter the scrollbar with more buttons and controls, consider providing expert shortcuts via meta keys. Ctrl-clicking an arrow button could scroll the user to the beginning and end of the content. Ctrl-clicking the track could instantly scroll to the corresponding position in the content, particularly useful if you’ve implemented Infoscroller. Ctrl-clicking the slider could pop open a mini dialog or text box to enter a page number, list item identifier, or Find criteria to jump to.
Left side scrollbar. There is some research suggesting we should usually be putting vertical scrollbar on the left side, rather than the right (see Kellener E, Barnes GM, & Lingard R (2001), Effects of scroll bar orientation and item justification, Proceedings of the Human Factors and Ergonomics Society 45th Annual Meeting). Having the scrollbar position consistent with the content alignment means less average slew distances for faster scrollbar use. In the same vein, putting the scrollbar on the left in a browser would shorten the distance between the scrollbar and the Back button for faster navigation. However, the advent of the scrollwheel may have made this idea obsolete.
Great question. Please see RockScroll, which is now standard in Visual Studio 2013 Preview: http://www.hanselman.com/blog/IntroducingRockScroll.aspx
RockScroll in turn inspired MetalScroll:
which in turn inspired RockMargin.
Also, Jetbrains Resharper plug-in for Visual Studio puts a vertical affordance to the right of the scrollbar. The information is displayed as little horizontal bars of different colors. These bars indicate a piece of code that can be improved. Clicking on a bar scrolls the code page to bring the code in question into view:
Also, most file comparison software uses fancy scrollbars. See Scooter Software's Beyond Compare 3.0, which puts an "infoscroller"-like affordance separate from the scrollbar. The affordance on the left is draggable like a scrollbar. In addition, to reduce the need for horizontal scrolling, there is a bottom pane which puts the current line from the left pane on top and the current line from the right pane below. Moving the info-scroller allows the user to scroll both documents simultaneously, which makes "merging" changes between two versions of the same document MUCH easier. Please see:
WinMerge has a different, equally scrollable, left-pane that functions like a scrollbar and duplicates the existing scrollbars. http://winmerge.org/about/screenshots/filecmp.png
Finally, Google Chrome integrates search functionality (the "find bar") into the scroll bar.
And Greg Raiz came up with the ABC Scrollbar:
And Overlay Scrollbars which minimize the non-client area:
And a research, gaze-enhanced scrolling techniques.
I like the Google Wave scrollbar- it seems like they've reconciled scroll bars with Fitt's Law.

TabCtrl_SetItemSize and user drawn tab controls

I have this Win32 user-drawn tab control that is created as:
CONTROL "Tab1",IDC_TAB_CONT,"SysTabControl32",TCS_BOTTOM |
TCS_OWNERDRAWFIXED | NOT WS_VISIBLE,0,14,185,88
I'd like for this control to have its tabs resize as never to have to see the "sliding arrows":
Now, pretty much everything about this control works as expected, except for that fact that it won't respond to TabCtrl_SetItemSize. Try as I may, the size I get for the tabs when I get to draw them (in the DRAWITEMSTRUCT passed to WM_DRAWITEM) is always the size that fits the longest caption in them and never the size I've set with TabCtrl_SetItemSize.
However, in the TabCtrl_SetItemSize documentation, it says that:
[TabCtrl_SetItemSize] sets the width and height of tabs in a
fixed-width or owner-drawn tab
control.
The only way I've managed to have a decent resizing is by setting a dummy string of the desired length in it by sending the control a TCM_SETITEM message, and writing the desired text in it at draw time. This is rather inconvenient and not a particularly nice hack.
Is there anybody who would know
Why TabCtrl_SetItemSize isn't working as expected? and/or
How to set the tab size properly?
Many thanks,
joce.
Setting TCS_OWNERDRAWFIXED style is not enough, you have also to add TCS_FIXEDWIDTH style.
The minimum size of a tab is at least icon width + 3 if icon is present.
If you have icons (imageList attached to tabControl), you might get those "sliding arrows" even with fixed width (if there is less space available than: number of tabs*(icon width+3)

Resources