Some weeks ago a user reported that the GUI of my program was shrink.
Today I started my laptop in multi-monitor mode and could reproduce the problem: at windows start up, the size of the main form was 325x243 pixels instead of 648x700.
I have no single line of code that controls the width/height of the form. The position is set like this: MainForm.Position:= poDefault. The user cannot resize the form ( BorderStyle:= bsSingle ).
What could cause such weirdness?
It is the second time when I start my laptop with additional monitors attached. The first time everything was ok. Could it be related to this multi-monitor configuration?
If the compiler generates no code related to form's size then it is like some external program injected code into my program to change its size. It is plausible. There are programs that are doing so in order to control how windows are spread over multiple monitors. I have one of them installed but it is not running at Windows start up.
The position is set like this: MainForm.Position:= poDefault
And that is the answer.
http://docwiki.embarcadero.com/Libraries/XE4/en/Vcl.Forms.TForm.Position
The form appears in a position on the screen and with a height and width determined by the operating system.
However there are other options like
poDefaultPosOnly: The form displays with the size you created it at design time, but the operating system chooses its position on the screen
poScreenCenter: The form remains the size you left it at design time, but is positioned in the center of the screen.
And many others.
Additionally, you may avoid fixing the issue and add a workaround instead: just set the form size fixed using http://docwiki.embarcadero.com/Libraries/XE4/en/Vcl.Forms.TForm.Constraints
Related
The RECT I get from WM_DPICHANGED is not scaled when I move a window between two monitors with different scaling, I get the same dimensions in pixels whichever monitor I move it to (which results in the window being too large for the monitor or too small for its contents). From using Spy++ it looks like this is the case for other applications too. The documentation
suggests that it should be scaled linearly with DPI by default.
My application is using Qt Quick, which sets PROCESS_PER_MONITOR_DPI_AWARE by default. I've also tried SetProcessDpiAwareness(PROCESS_SYSTEM_DPI_AWARE) in my own code, which works as I want in terms of window sizing, but the contents are blurry on the secondary monitor (as you'd expect), and SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2) which works like the Qt default but scales the window decorations correctly too. In all 3 cases the window contents are scaled correctly.
I'm wondering if there is an issue with Windows itself, or if an update has changed this behaviour, as no application currently resizes correctly for me, and I'm pretty sure some applications, e.g. Explorer and Edge used to at least. I'm currently using Windows 10 17134.
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
I would like to write a program that can mirror a portion of the main display into a new window. Ideally this new window could then be displayed on an external monitor. I have seen this uiltity for a flightsim that does this on a pc (a multifunction display extractor).
CLick here for a screenshot of the program (MFD Extractor)
This would be a live window ie. constantaly updated video display not just a static graphic.
I have looked at screen magnifiers or vnc clients for ideas but I think I need to write something from scratch. I have tried to do some reading on osx programing but where do I start in terms of gaining access to the display? I somehow need to extract the graphics from a particular program. Is it best to go near the final output stage (the individual pixels sent to the display) or somewhere nearer the window management stage.
Any ideas or pointers would be much appreciated. I just need somewhere to start from.
Regards,
There are a few ways to do this:
Quartz Display Services will let you get access to the video memory for a screen.
Quartz Window Services (a.k.a. CGWindow) will let you create an image of everything that lies below a window. If you create a borderless, transparent, empty, high-level window whose frame occupies an entire screen, everything below it will be everything on that screen. (Of course, you could create a smaller window in order to copy a section of the screen.)
There's also a way to do it using OpenGL that I never fully understood. That technique is demonstrated by a couple of code samples, OpenGLScreenSnapshot and OpenGLCaptureToMovie. It's more or less obsoleted by CGWindow, though.
Each of those will get you an image that you can then show or write to a file or something.
To show an image, use NSImageView or IKImageView. If you want to magnify it, IKImageView has a zoomFactor property, but if you want nearest-neighbor scaling (like Pixie, DigitalColor Meter, or xScope), I think you'll need to write a custom view for that (but even that isn't all that hard).
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