I started looking for the touch equivalent of GetSystemMetrics(SM_CXDOUBLECLK | SM_CYDOUBLECLK), but any list of values will do. So far I have found these: https://msdn.microsoft.com/en-nz/library/ee500273.aspx
That structure isn't part of Windows any more. The current structures are internal to Microsoft; however, the current values are:
200 himetric units in X and Y for the touch to be considered a tap;
450 himetric units in X and Y for two taps to be considered a double tap.
Related
I'm using LWJGL 2.9.3 to create a window and retrieve mouse coordinates via LWJGLs Mouse.getX(),getY() methods. The results by those methods and by events via getEventX() are equal.
The coordinates I get back are correct using linux (ubuntu gnome, dm: i3) but aren't when using windows 8. (I considered wrong monitor settings due to second monitor but couldn't achieve anything by disconnecting/resetting/changing them)
Here are 2 images with estimations of the coordinates I get on both operating systems.
Correct, linux:
Incorrect, windows:
When activating fullscreen, I get data for both variables, the X coordinate seems to fit, the Y coordinate is somewhat off and changes for multiple clicks on the same location.
Here is the entire code I'm using for this example:
https://gist.github.com/Geosearchef/5889a13edd6b983959e837a8506170af
Does anyone have any idea what could be causing this? A bug with LWJGL? I was already using that exact version on Windows and was able to do it. A problem with my installation?
UPDATE: ((WindowsDisplay) Mouse.implementation).mouse.last_x has the correct value, ((WindowsDisplay) Mouse.implementation).mouse.last_y is correct if you set its origin at 1/3rd from the top. Below that it get's negative --> getting clamped. I don't know though why x gets set to -1.
UPDATE: The mouse implementation fails due to the Display class returning 0, 100 as width and height. This is ignored in the case of fullscreen. Width and height are set correctly in the beginning but are later overriden by an update (resize) call from the underlying implementation.
I've now figured out the problem. I used the natives of and old LWJGL implementation (2.9.1) which were stored in my project files.
I'm using accessibility with the AccessibleObjectFromPoint function, and I'd like it to work correctly on a per-monitor DPI environment. Unfortunately, I can't get it to work. I tried many things, and the situation for now is:
My app is marked as per-monitor-DPI-aware in the manifest. (True/PM)
I use GetCursorPos and then AccessibleObjectFromPoint.
How can the problem be reproduced:
Have two monitors, one with 100% DPI, the other with 125%.
Run Chrome on the 125% monitor.
Use AccessibleObjectFromPoint on one of the tab names, it won't work.
It works with some apps (DPI-aware, it seems, like explorer), but doesn't work with others. I tried several relevant functions, such as GetPhysicalCursorPos and PhysicalToLogicalPointForPerMonitorDPI, but nothing works.
It's worth noting that Microsoft's inspect.exe works as expected.
I’ve been struggling with this exact same problem for several weeks and can now tell you my findings. Unfortunately I can’t give you more than a hint of code, because the project I am working on, is proprietary.
The issue started at Windows 8.1. The problem did not exist on Windows 7 or Vista, because AccessibleObjectFromPoint always used raw physical coordinates, as documented here: https://msdn.microsoft.com/en-us/library/windows/desktop/dd317984(v=vs.85).aspx .
“Microsoft Active Accessibility does not use logical coordinates. The following methods and functions either return physical coordinates or take them as parameters.” This has not been true since Windows 8.1.
AccessibleObjectFromPoint now uses a flawed calculation that cannot always find the correct window for reasons similar to my question here: High DPI scaling, mouse hooks and WindowFromPoint .
My findings lead me to one conclusion: The API is broken. This does not mean it is not possible though.
Possible solutions I have partially tested that seem to work follow.
Prerequisites are that you
1/. Make your process per monitor DPI aware, NOT USING THE MANIFEST (more on that later).
2/. Determine the hWnd of the window you want to query (WindowFromPoint() variants)
3/. Determine the monitor DPI of the queried hWnd
4/. Determine the DPI of your process
5/. Determine the DPI of the queried hWnd
6/. Determine the monitor origin and offset for the queried hWnd (MonitorFromWindow() and GetMonitorInfo() )
Next, depends on your platform
Windows 10.0.14393+
Write a function that finds the IAccessible (AccessibleObjectFromWindow() ) from the top level window, and then recursively call IAccessible::accHitTest until you reach the bottom-most IAccessible and perhaps ChildID data. Return that as if you would call AccessibleObjectFromPoint.
To call it successfully, you will need to scale the (x,y) co-ordinates into the scale system of the queried hWnd, using the DPIs and co-ordinates fetched in the list above. Watch out for systems where monitors are not the same size or if monitors are partially offset, or above and below.
And now for the important part for 10.0.14393 – Set your thread to the same DPI_AWARENESS_CONTEXT of the hWnd you are querying. Now call your new function. Now revert your thread to monitor DPI aware, and voila, it works, even if the window is not maximised. This is why you must not use the manifest.
If you are on Windows 8.1 to 10.0.10586 you have a tougher task.
Instead of calling accHitTest, as above, you have to recursively call AccessibleChildren and iterate the call IAccessible::accLocation to determine if your test point is within each child. This is tricky and starts to get really messy when you get to e.g. combo boxes in products like Office, which is only system DPI aware.
That’s all I can give you for now.
To do it successfully on multi-platform (mine has to work from Vista to Windows-Current) the only really safe bet is to write a wrapper DLL in C++ that can determine at runtime which OS it is on and change code path accordingly. The reason you want to do it in C++ is to avoid passing IAccessible objects across the .Net/unmanaged marshalling boundary. You can call IUnknown::Release on objects you don’t need to return n the unmanaged side. You can do it all in .Net, but it will be slow.
P.S. also watch out for Chrome returning infinite trees where parents are children of their parents, some snity checks are required. Also, Chrome does not return accRole correctly, and will give you HTML tags instead of VT_I4.
Good luck
A fairly workable solution is as follows, in your IAccessible recursive function:
Use getwindowrect to capture the physical right on main window
Use accChild.accLocation in loop to capture left and Width on each Object
Add this simple test
If l > rct2r.Right And l > arrIACC.x2 Then
arrIACC.x2 = l + w
End If
if dpi = 100 then no Object is furter out than physical right
if dpi > 100 then closebutton is...x pix offset
Use the difference to rescale all values you are in use of Width
arrIACC.w1 = CInt(((-rct2r.Left + arrIACC.w1) / arrIACC.x2) * rct2r.Right)
This solution is from an Excel plugin I have developed, I was testing the Width of the quick access toolbar qat and my result was +- 5 pixels regardless of any DPI.
For some time now, I've been working on a series of GUIs. I use a Mac running OSX to write all of my code, and the problem I've encountered is that it there are deviations in appearance when the GUIs are used in windows, some of which are minor, and some of which are very significant.
1) The text in the windows version is substantially larger overall. This results in some of my button titles simply going off the button, or panel titles moving beyond the panel.
2) Axes appear to be different dimensions between Mac and Windows. i.e. An axis that appears square on my Mac will appear elongated or rectangular on windows, and vice versa.
3) Graphical displays are different. This is the real problem. Some of my GUIs use axes to display text and model chemical reaction animations. On the Mac, they look perfectly fine, but on the windows system, the sizing is completely off.
I've set all "Units" to "characters" as suggested by the Mathworks help page, and I do not specify any fonts to allow each system to use its default. I have however, specified font sizes, but apparently, 12 point font on windows appears very different from 12 point font on mac.
Are there any ways around these problems? I thought setting a specified font size and allowing for use of default fonts would fix this, but it hasn't, and I'm a little dry for ideas at this point.
Try working in 'pixels' or absolute size units instead of 'characters', and apply a scaling factor to your font sizes.
Setting 'Units' to 'characters' is probably the wrong way to go for portability, and could be the main cause of your display sizing issues. Which specific Matlab page recommended that you do so? Was it talking about cross-platform portability? The characters unit is very convenient to work with, but it is tied to the font metrics for the default system font. (See the doco for Units property at http://www.mathworks.com/help/matlab/ref/axes_props.html). That's going to differ between different operating systems. Working with 'pixels' or inches/centimeters/points, which are absolute, will probably give you more uniform results across operating systems.
And you're not wrong: OS X tends to display fonts of a given size on screen smaller than Windows does. (Generally; YMMV depending on your display DPI and system settings and other things.) For example, I run my terminals and text editors at 10 or 12 points in Windows, but 14 point or larger on Mac. So apply a scaling factor to the font sizes you set in your GUI. Figure out what looks good on Mac, and then scale it in your code to something like windows_font_size = floor(mac_font_size * 0.8) and see how it goes.
If you want to be more precise in scaling, you could grab the ScreenPixelsPerInch and ScreenSize root properties with get(0,...). You may also be able to call down in to Java code to get precise font metrics info to help with font scaling choices.
Either way, you're going to have to test your code on both systems instead of just expecting it to work portably. If you don't have ready access to a Windows development system, consider setting up a Windows VM on your Mac. With file sharing between the two sides, you'll be able to try your code out on both platforms right as you work with it.
I encountered this problem as well.
Calling this function within the FUNCTIONNAME_OpeningFcn might alleviate your issues:
function decreaseFontSizesIfReq(handles)
% make all fonts smaller on a non-mac-osx computer
persistent fontSizeDecreased
fontSizeDecreased = [];
if ~ismac()
% No MAC OSX detected; decrease font sizes
if isempty(fontSizeDecreased)
for afield = fieldnames(handles)'
afield = afield{1}; %#ok<FXSET>
try %#ok<TRYNC>
set(handles.(afield),'FontSize',get(handles.(afield),'FontSize')*0.75); % decrease font size
end
end
fontSizeDecreased=1; % do not perform this step again.
end
end
We are having an application ported from Windows to Mac OS, and colors are being displayed differently on both platforms. Here's an example:
In this case, we're telling the application to use green 0,140,0 and blue 25,0,75. On windows, this works great (top image). On the Mac, apparently OS X decides to "reinterpret" the colors and displays them differently (bottom image).
Is there something we can do to tell the operating system to stop being creative with our color definitions? It's going to be hard to make things look good on both platforms if the mac arbitrarily changes our color definitions by ~10%.
Edit: Here's an example of the code we're using to set the color for the blue used above:
m_colour = CGColorCreateGenericRGB(25 / 255.0, //r
0 / 255.0, //g
75 / 255.0, //b
1.0); //a
Thanks.
The Mac uses a complex colourspace system called ColorSync to ensure colours appear identical on different devices. As a result, colours may sometimes be shifted slightly in the RGB space so that they appear to the eye identical on properly calibrated displays, printers, etc.
If you show us the code you use to generate that shade of green, we can show you how to modify it to avoid this colour correction. However, unless there's a pressing reason why you want to avoid it, it's usually better to let it happen, as you do not have a wide range of display models to test against.
Edit: CGColorCreateGenericRGB() creates a colour in the generic RGB colour space, so it's going to end up shifting slightly depending on your display calibration. Unfortunately for you, it is no longer possible (as of Mac OS X 10.4) to create an instance of CGColor that is device-dependent (and therefore not subject to calibration.) You can, however, create a CGColor in the colour space of the target drawing context--that will tell Quartz that no conversion is necessary.
If you've created the context yourself, you should keep a reference to the colour space you used (of the type CGColorSpaceRef.) If it's at the Cocoa level (such as the context created by -[NSImage lockFocus] or by -[NSView drawRect:] then you should use the relevant NSColor APIs instead of the CGColor APIs (i.e. +[NSColor colorWithDeviceRed:green:blue:alpha:].)
If you must use Quartz drawing, you can call CGContextSetRenderingIntent() to tell the context how you want to have colours converted, but there is no guarantee that a conversion will not take place.
So I've recently had to create a report that emulates a Canadian customs form. The problem is that the report is printed on 11" x 14" paper, but uses a metric layout. As my FoxPro installation is on a machine with US-English units-of-measure, FoxPro tries to oblige by using an English ruler, and doing snap-to-grid on inch-based measurements. This creates some minor design issues obviously.
I understand that the reports are really just tables in disguise, and I have figured out how to turn on the Metric ruler (instead of the English one) by changing a record, and that is working as intended. However, the snap-to-grid functionality appears to want to snap on 48 units-to-an-inch, instead of something Metric. So moving a box around using a mouse results in the box being offset (again) in English measurements.
To get around this, I have taken to openning up the report as a table and manually converted all Metric units with a spreadsheet, and entered the offsets and sizes by hand. While this has worked well and appears to be very accurate, it's still error-prone.
So the question is, how do I get FoxPro 8 to snap-to-grid in Metric units on the report, so that I don't have to keep re-entering numbers by hand? It would be nice to get FoxPro to accomodate Metric in a fashion where I can align objects in the report using a mouse, rather than punching them in as numbers and "flipping" the report into design view to check it.
For reference, currently there are the following translations:
25.4 mm = 1 inch = 10,000 report units = 48 grid snap points
Obviously I'd like something closer to this:
25.4 mm = 1 inch = 10,000 report units = 25.4 grid snap points
Note: Yes, I have considered setting up a Virutal Machine with FoxPro that uses a Metric install, i.e. a Windows XP install set up for Canada. However, that will take another day or so to get the installation done, along with the rest of the development environment, so I'm trying to avoid that.
Hidden unless you've been exposed to more of it...
Modify your report.
Right-click, get to properties of the report.
On the tab for Ruler / Grid, there is a combobox which is defaulted to ruler of "inches", but you can change it to Metric/cm or Pixels. Below that is your grid snap and you can change the default of how many pixels to snap to.
Additionally, if you use your cursor keys, you can move the controls one pixel at a time for more precise alignments as needed. And if you need to resize a control's width, if you hold the Ctrl key down and use the arrow keys left/right, will shrink / strecth one pixel at a time instead of moving the control. Likewise for the moving and sizing if you pick multiple controls, they will ALL move or resize respectively.
HTH
Just spoke with a freind lastnight who has VFP8 installed. Based on that version, there MIGHT be a way to get metric for your reports. There is a setting on the reports from showing based on PIXELS, or SYSTEM METRIC. If you system configuration is based on inches, so too is the report. If you change your system metric to that of centimeters (or whatever equivalent it would be), so too should the report respect in design time.
HTH