Forum
× General discussions, feature requests for CodeTyphon Project and discussions that don't fit in any of the other specific CodeTyphon forum categories.

Question Win64 API processing of non-user messages on Win10x64 Pro using Typhon64

  • Glenn Hudson
  • Topic Author
  • Offline
  • Fresh Boarder
  • Fresh Boarder
More
1 month 2 weeks ago #13505 by Glenn Hudson
This attached code from the free pascal website describes a method of processing windows messages that has worked well for me on Win32 or Win64 systems when built using the Typhon32 compiler. I would like to build the software using Typhon64 to port it to native Win64 code but can not get the WndCallback function to respond when built this way, only with Typhin32. I have spent many hours researching this on several FPC, Delphi, Lazarus and Pilot Logic sites but have not found a single answer that works. Does anyone know for a fact whether or not this will ever work when compiled with Typhon64 and run on a Windows 10 64 bit system?

Thank you in advance for any advice or assistance.
ghudson58

File Attachment:

File Name: WndCallbac....pas.txt
File Size:1 KB
Attachments:

Please Log in or Create an account to join the conversation.

  • Sternas Stefanos
  • Sternas Stefanos's Avatar
  • Offline
  • Moderator
  • Moderator
  • Ex Pilot, M.Sc, Ph.D
More
1 month 2 weeks ago #13507 by Sternas Stefanos
Did you try

PrevWndProc:=Windows.WNDPROC(SetWindowLongPtr(Self.Handle,GWL_WNDPROC,PtrInt(@WndCallback)));

PilotLogic Architect and Core Programmer

Please Log in or Create an account to join the conversation.

  • Glenn Hudson
  • Topic Author
  • Offline
  • Fresh Boarder
  • Fresh Boarder
More
1 month 2 weeks ago - 1 month 2 weeks ago #13508 by Glenn Hudson
Thank you for your quick reply Sternas. Yes, that is how I always had it defined while building code using Typhon32 and it worked perfectly on both WIn32 and Win64 systems for years. I do believe your suggestion may be at the root of the problem since I'm not sure that for native 64 bit code that PtrInt with return the correct pointer to the callback. That was why I started trying either PtrUint and Long_Ptr, both of which compile fine and make sense to me. However, while either compiles fine, the callback never responds to my WM_INPUT message from multiple USB keypads as it did when building with Typhon32. Any other thoughts?

Glenn
Last edit: 1 month 2 weeks ago by Glenn Hudson.

Please Log in or Create an account to join the conversation.

  • Glenn Hudson
  • Topic Author
  • Offline
  • Fresh Boarder
  • Fresh Boarder
More
1 month 2 weeks ago - 1 month 2 weeks ago #13509 by Glenn Hudson
I've solved the problem I was experiencing and wanted to share my findings to possibly help others avoid hours of wasted time that I spent with this issue. Years ago when I first wrote the code to accept and distinguish keypresses from 4 separate USB keypads for a competition scoring system, the only header translations for handling "WM_INPUT", raw input Windows messages was the "JwaWinUser" unit supplied by the JEDI project. I've been using the same code for years with no trouble at all when my software was compiled using Typhon32 to run on 32 bit and 64 bit(using WOW64) Windows systems. The problem was that the "JwaWinUSer" unit I was using for the Win32 API was last updated several years ago and no longer seems to have acceptable header translations for compiling native Win64 applications using Typhon64. After digging deeper into the definitions for the Win32 API procedures and functions I needed for my software, I found significant differences to what I was reading on the Microsoft website and started investigating further. What I ultimately discovered was the the current "windows" unit already supplied with FPC now includes much more recent header translations for much of the Win32 API related items and decided to try working with it. I completely removed the "JwaWinUser" unit and used the "windows" unit for all my variables, procedures, and functions and modified my code accordingly. The end result is that I was able to successfully recompile my software into native Win64 executables and everything now works perfectly. I hope this ends up helping others avoid the same frustrations I endured when re-writing 32 bit software to native 64 bit Windows software requiring the Win32 API.
Last edit: 1 month 2 weeks ago by Glenn Hudson.

Please Log in or Create an account to join the conversation.