FB WinSpy

[Pierre Bellisle]

Hey,

Remember this SDK-DDT code generator by Börje Hagsten...

PB WinSpy++++ The ultimate RAD (Rapid Application Development) tool for PB/DLL, PB/WIN.

The idea of only clicking on an existing window or dialog
to get FreeBASIC code generated to recreate the same pattern is appealing.
To me, mainly  because I will have tons of PowerBASIC code to migrate.

I might reinvent the weel, but before doing so, if I do...

Is there any plan to integrate this feature in FireFly or in any other apps?
If not, does anyone know of an already existing application devoted to this?

Thank you,
Pierre

[José Roca]

I once played with the idea and asked Börje for the source code. One problem is that I don't know how to detect if the application whose GUI we want to recreate is running virtualized or if it is DPI aware. This makes a difference in the returned values for coordinates and sizes and problems with drag and drop. Maybe the only solution is compile the tool in two versions, one being dpi aware and the other not, and use the appropiate one in each case. Unless you're working at 96 DPI, ça va de soi...

[Pierre Bellisle]

For those who might be interested in Börje PB-WinSpy here is the link... PB-WinSpy source code...

Jose, on my side I'm always on 96, but I get your point.
Also, you know that I'm not allergic to Dialog.

The way I was seeing it, if I ever start this work, would be to literraly use
the existing WinSpy which can crerate PB-DDT and PB-SDK and add code generation option for
FB-SDK and FB-DynamicDialog. I already got a FreeBASIC Dialog .bi file that works pretty well.

I did almost nothing on the "DPI aware" side but WinSpy could look into the application manifest for dpiAwareness.
Or maybe call GetProcessDpiAwareness(PROCESS_DPI_UNAWARE/PROCESS_SYSTEM_DPI_AWARE/PROCESS_PER_MONITOR_DPI_AWARE)...
So a supplemental "DPI" option coul be added to WinSpy.

This said, I dont want a full blown application.
Just a little smart program that does the essential like PB-WinSpy already does, but for FB.

[José Roca]

I'm aware of GetProcessDpiAwareness, but requires WIndows 8.1 at least, and I'm using Windows 7.

> So a supplemental "DPI" option coul be added to WinSpy.

This does not solve the drag and drop problem.

If you ever use a high DPI setting (I'm using 192) and try to do a drag and drop operation between a DPI aware application and a virtualized one, or vice versa, e.g. dragging a file from Explorer, you will quickly notice it.

[Pierre Bellisle]

Does this drag and drop problem's is the one described in DPI and Device-Independent Pixels ?

I know you enough to be sure that you already also know about IsProcessDPIAware(Vista).
Quick test seems OK under Seven, but I guess that it does not fit the bill for you since you consider DPI detection not to be straightforward enough.
Still, reading the manifest resource could be a valid clue.
But again, I know almost nothing about high DPI so maybe you want something else...

[José Roca]

My CWindow class calls IsProcessDPIAware to know if the aplication is DPI aware and do scaling, but that function can't be used to know if the other application whose GUI I want to clone is DPI aware or not.

Looking for a manifest could work if the application uses a manifest to set DPI awareness, but an application can be made DPI aware by other means, without using a manifest, like calling SetProcessDPIAware (there are new functions in the latest Windows versions).

When you move the cursor of Börje's PB WinSpy to select the GUI element, you can't point directly at it, but at a different position. In the attached picture, the Toolbar is detected when I point the cursor at the position marked in red. And if the GUI element is at the bottom or at the right side of the monitor, you can't select them because there is no room to move the cursor.

[Pierre Bellisle]

Interesting stuff,

I might have a look to GetPhysicalCursorPos() PhysicalToLogicalPoint() LogicalToPhysicalPoint() to see if it rings a bell.

About IsProcessDPIAware, probably a mix of CreateRemoteThread/VirtualAllocEx/WriteProcessMemory/ReadProcessMemory could be used with success...

[Pierre Bellisle]

On your side Paul, any thought on my first post?

[Paul Squires]

On your side Paul, any thought on my first post?

It is certainly an interesting idea for sure, but my direction would most likely be to write a program that takes PB's DDT code and converts it to Jose's CWindow statements. In the longer term I want to build a visual designer on top of WinFBE, something that lighter and easier to maintain than FireFly. Something that can generate multiple code backends.

[Pierre Bellisle]

Paul,
Thank for you answer :-)

-

Jose,
Quick test with some Greg Turgeon's code seems to work ok.
Under Seven, injected IsProcessDPIAware give response...

Pierre

[Pierre Bellisle]

Hola Jose,

I finally did at 150%... It's a mess for the least...  :-)

So I added a button to select the use of GetPhysicalCursorPos() or GetCursorPos()
in a quick compile of Börje's WinSpy++, It works perfectly and no more offset are induced.

As for IsProcessDPIAware DLL injection code test, this is also working good.
If you did not already produced your own code,
I can do some clean up and send you a zip...

Pierre

[José Roca]

I haven't done anything yet, so if you're willing to share the code I will look at it. Thanks very much.

[Pierre Bellisle]

Here it is, quick code cleanup, nothing fancy, but all is there I think...

Low heart beat you will ear is a positive answer to IsProcessDPIAware that come from the injected process...

Used PowerBASIC 9.07 using PB-incluses.

Inject02.rc
Inject02.bas
Inject02Dll.bas

DpiNotAware01.rc
DPIAware01.rc
DPIAware01.bas

PBWinSpy.bas and all dependent files
with DPI button added for GetPhysicalCursorPos()/GetCursorPos().

DpiAware.zip

Pierre

[José Roca]

Hi Pierre,

Not sure of what you intend to do. There is not offset problem if Börje's tool and the other application are both running DPI aware, or both running virtualized. The problem comes when one of them is running virtualized and the other not.

This happens because, in an application running virtualized, a gui element that looks, for example, 200 pixel wide at 192 DPI, in fact it is 100 pixels wide.

[Pierre Bellisle]

Well the code adress thoses...

Q> When you move the cursor of Börje's PB WinSpy to select
the GUI element, you can't point directly at it, but at a different position.

WinSpy++++'s DPI added button when flipped, can get the good xy-point by
using GetPhysicalCursorPos instead of GetCursorPos.

Q> My CWindow class calls IsProcessDPIAware to know if the aplication
is DPI aware and do scaling, but that function can't be used to
know if the other application whose GUI I want to clone is DPI aware or not.

Inject.exe/DLL will force DpiAware.exe or any other exe to reaveal if
it is dpi aware by injecting and calling IsProcessDPIAware from inside it.
Try it with exe that are or not dpi aware...


Pierre

[Added for curious: IsProcessDPIAware will return always true if DPI scale factors is less than 150%]