Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (4)

Resolved WindowFromPoint in 64Bit application

  1. Issue
0
Votes
Undo
  1. Mayller Lopez
    Mayller Lopez
  2. PowerBuilder
  3. Thursday, 17 December 2020 03:35 AM UTC

Hi,

I have an application which running smoothly in 32bit, but my client now requested it make it as 64bit. So i've gone thru migration from PB12.1 to PB12.6 B4138. Now I have a problem with one windows API (WindowFromPoint) it doesnt return proper handle in 64bit exe, but if I run the source which is in 32bit its working properly.

Function is declared from uo, as no matter what data type i use to declare, longptr, long or ulong still doesnt return correct value. Btw longptr it just return 0

Function longlong WindowFromPoint(long xx, long yy) library "User32.dll"

my uo which is calling the ext funtion instance declared as:

longlong  hWnd, hPic, hLab

contructor event:

hWnd = Long(Handle(This))
hPic = Long(Handle(Glyph))
hLab = Long(Handle(Label))

this function (iswithin - bool) always returns false as ll_hnd and hWnd didnt match, while in 32bit it always match and working properly.

longlong ll_hnd
POINT lpPoint

Externs.GetCursorPos(lpPoint)
ll_hnd = Externs.WindowFromPoint(lpPoint.X, lpPoint.Y)

Return  (ll_hnd = hWnd Or ll_hnd = hPic Or ll_hnd = hLab) And IsParentActive()

The iswithin function is called from mousemove event:

IF ObjectAtPoint <> This AND IsValid(ObjectAtPoint) THEN ObjectAtPoint.TriggerEvent("MouseLeave")

IF IsWithin() THEN
    ObjectAtPoint = This

    SetTimer(hWnd, 1, 1, 0)
    IF FDown THEN
        If Globals.ib_new_ui Then
            
            If FCaptured Then StickyHighlight(cPressed) Else StickyHighlight(cHover)
        Else
            
            StickyHighlight(cBtnFace)
        End If
        //IF FCaptured THEN Lower(2)
    ELSEIF FCaptured THEN
        
        Lower(1)
    ELSE
        Raise()

    END IF
    ShowHint()
END IF

When iswithin return false, the button that supposed to be clickable is just like disabled. What could be wrong with this api WindowFromPoint?

This is the only api that is blocking my application and we cannot use it.

Thanks,

Mayller

 

  1. 64-bit
  2. API
  3. DLL
Call stack availabile in PB Error object
Get returned value when closing modal IE browser
Accepted Answer
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Thursday, 17 December 2020 04:15 AM UTC
  2. PowerBuilder
  3. # Permalink

Greetings, Mayller - 

It appears to me the WindowsFromPoint API function takes a POINT structure as its lone argument:

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-windowfrompoint

I believe an older form of this API function supported passing the X & Y coordinates of the point in question as separate arguments, but this is not the official, documented syntax. Try passing a POINT structure instead and see if that works. Also, be sure the point coordinates are in screen coordinates (pixels), not PBU's.

Regards, John

Comment
There are no comments made yet.
Responses (4)
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Friday, 18 December 2020 20:12 PM UTC
  2. PowerBuilder
  3. # 1

I'm attaching a zip file containing exported source for two objects: Structure s_point and Window w_main.

Normally I would've attached a pbl, but because you are using PB 12.6 and since I have no version that old, I exported the source from a later version of PB.

This is a very small, simple, single-window you can easily add to a new test app. The window utilizes the GetCursorPos, WindowFromPoint and GetWindowTextW API functions. It works from PB 2019 R2's IDE, as well as from a compiled 32-bit exe and a compiled 64-bit exe. There is nothing in either object that should preclude these two objects from importing into PB 12.6. But, if there is a problem, you can edit the w_main.srw source file and copy/paste the small amount of code it contains.

With the app running, as you move the cursor around over the app and over other apps and the Windows desktop, task bar, etc. the app will display the screen coordinates of the cursor's position, the Windows handle of the window/control that the cursor is over, and when possible it displays the title/text of the window/control the cursor is over.

I was VERY surprised that when I initially coded the WindowFromPoint external function declaration to pass a point structure to the WindowFromPoint API function, PB produced an error at runtime concerning a problem with the execution call stack - indicating that passing a point structure was NOT the proper way to invoke this API function... in spite of what Microsoft's online documentation states. So, I passed in the X & Y coordinates as PB Long's (exactly as you had initially had it), and it works. In both 32-bit and 64-bit. Not sure why it needs to be this way.

Create a new workspace, create an Application target & pbl & application object, then import the s_point structure, then import the w_main window. Open(w_main) from the application's Open event and it should run from within the IDE. I created a PB Project object to produce a 32-bit exe and another to produce a 64-bit exe. Both work.

If I were to venture a guess, the issue you're experiencing is somehow related to your handling of window handles.

I hope this helps you out.

Regards, John

Attachments (1)
WindowFromPoint.zip
Comment
Mayller Lopez
  1. Mayller Lopez
  2. Wednesday, 23 December 2020 01:22 AM UTC
Hi John,

Did not notice you authored the article Interfacing PB application :). You just made a revision what was the revision? BTW managed to resolved it partially im still in the process of migrating the rest of the codes. What I rely on longlong specially on handle related calls, also the point str i change it to longlong somehow it works as expected. Longptr is crashing the app or sometimes just returning 0. Anyway thanks for the effort also it gives me more ideas.
  1. Helpful
John Fauss
  1. John Fauss
  2. Wednesday, 23 December 2020 05:16 AM UTC
I'm glad to hear you are making positive progress, Mayller.

I believe Govinda Lopez has added some omitted tags to Part 4. I'm currently revising Parts 1, 3 & 4 and hope to submit the revised versions for review/approval over the holidays. There are no major changes being made, but there are a few things Andrew Barnes has raised in the comments regarding PB nulls in Part 3 that I felt should be addressed and explained. Part 1 will soon describe passing arguments read-only to external functions (which is not well-documented in the help or online publications), clarify some points differentiating passing arguments by value versus passing by reference, add a list of the typedef'd character datatypes in the WIndows API, among other minor changes. Part 4 changes will also be minor.

If you have any suggestions or criticism regarding these articles, I welcome them. I would please encourage you to leave a comment in the appropriate article(s), or you (or anyone else) are welcome to email me: jfauss-at-cox-dot-net... please mention PB Tutorials in the subject line to ensure your email gets through.

Good luck with your project!
  1. Helpful
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Thursday, 17 December 2020 15:21 PM UTC
  2. PowerBuilder
  3. # 2

Your external function declaration for the WindowFromPoint API function should not include the keyword "REF", as this causes the 8-byte memory address of the POINT structure to be passed as the argument value instead of passing the 8-byte POINT structure by value, as the API definition states (computers insist on doing exactly what you tell them to do, darn it wink). See if that helps.

Comment
Load more comments
Mayller Lopez
  1. Mayller Lopez
  2. Friday, 18 December 2020 01:47 AM UTC
Hi John,

Still didnt work it just returning 0. The keyword "REF" isn't different from what was mentioned here: https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/305-interfacing-pb-applications-with-the-windows-api-part-4. Regardless I put REF or not the return still null and data type is LongLong or Longptr both didnt work.
  1. Helpful
John Fauss
  1. John Fauss
  2. Friday, 18 December 2020 04:25 AM UTC
Well, given that there is no 64-bit debugger, you're going to have to take apart the IsWithin function step by step and display each step. Are the X,Y coords in the POINT structure valid? Can you verify that the API function is returning zero or are you assuming it does because the IsWithin function returns False? Are the various Handles valid? It's not inconceivable that PB12.6 contains a bug, as this was SAP's initial release that supported 64-bit executables. Can you produce a small test app (single window, no DB connection or data retrieval, etc.) that demonstrates the same issue? If so, zip it up and post it here and I can try migrating the test app to PB 2017 R2 and see how it tests out.
  1. Helpful
Arnd Schmidt
  1. Arnd Schmidt
  2. Friday, 18 December 2020 09:31 AM UTC
Check your declarations for handles and use LONGPTR instead of LongLong.

Furthermore typecasting "hWnd = Long(Handle(This))" is a bad idea :-(

https://community.appeon.com/index.php/qna/q-a/dual-platform-32-64-longptr-vs-longlong
  1. Helpful
There are no comments made yet.
Mayller Lopez
Mayller Lopez Accepted Answer Pending Moderation
  1. Thursday, 17 December 2020 04:48 AM UTC
  2. PowerBuilder
  3. # 3

Thanks John,

I noticed that also WindowFromPoint is using POINT so i made external as per below:

Function longlong WindowFromPoint(REF POINT lpPoint) library "User32.dll"

But its returning 0 , with regards to point coordinates that Externs.GetCursorPos(lpPoint) is returning in pixel or PBU. below is the point structure:

global type point from structure
    long        X
    long        Y
end type

Regards,

Mayller

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.