• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • ToolTipMsg( hWndTT, TTM_ADDTOOL, 0, ToolInfo ) returning 0

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

Resolved ToolTipMsg( hWndTT, TTM_ADDTOOL, 0, ToolInfo ) returning 0

  1. Advice
0
Votes
Undo
  1. Subrat patra
    Subrat patra
  2. PowerBuilder
  3. Tuesday, 21 November 2023 07:56 AM UTC

Hi All,

we are trying to migrate our application from 32 bit to 64 bit. 

Now as per suggestion by migratation document i have chaged the cbsize to 64 , now i am getting error while calling ToolTipMsg( hWndTT, TTM_ADDTOOL, 0, ToolInfo ).

I am not sure what other things i need to change. can you please guide me.

I am using PB2022.  One more thing after I changed the value to support 64 bit , when I run the application from PB2022 IDE by selecting 'X86' from the drop down its still working fine, but it throws error while select X64. So not sure when the value of cbsize effective.

 

Vertical Navigation
PowerBuilder 2019R3 / 2021 application terminates ...
Accepted Answer
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 21 November 2023 14:37 PM UTC
  2. PowerBuilder
  3. # Permalink

Hi, Subrat -

You have several related issues that should be addressed in order to utilize WinAPI calls in 64-bit:

1. Structure definition changes. Any structure that contains a Windows handle should use the Longptr datatype.

2. Any structure that includes its size as an element (like cbSize) has to have the correct value. How to know the correct value to use? See below.

3. Your code should be refactored. For example, use Longptr for values that contain Windows handles (such as the return value from the PowerScript Handle() function) and memory addresses (like what is used in the lstrcpy API function call).

4. Although you may continue to pass ANSI strings between your PB app and Windows, both use Unicode, so why continue perform a lot of unnecessary, behind-the-scenes data conversions? Use the Unicode version of the API functions (hint: Their names end in "W", for "Wide characters").

The rules for how structure elements are laid out in memory differ slightly between 32-bit and 64-bit. This can have an impact on the overall size of a structure in addition to the increase in the size of some elements. A few years ago I published a four-part series of PB tech articles concerning the interfacing of PB applications to the Windows API. Part 2 covers 32-bit to 64-bit migration issues:

    https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/303-interfacing-pb-applications-with-the-windows-api-part-2

This series of tech articles was researched and written for PB developers just like you. I encourage you to invest a little time and learn both why and how things are different between 32-bit and 64-bit WinAPI calls. 

Best regards, John

Comment
There are no comments made yet.
Responses (9)
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 21 November 2023 09:39 AM UTC
  2. PowerBuilder
  3. # 1

Please show us the declaration of your external funciton "ToolTipMsg". Most likely you'll have to change the hwnd parameter to be of type "longptr".

What's the definition of TOOLINFO? Is it a structure? Possibly some types have to change too.

 

Comment
Load more comments
Benjamin Gaesslein
  1. Benjamin Gaesslein
  2. Tuesday, 21 November 2023 12:44 PM UTC
The choice of long vs. longptr shouldn't require a bitness check because LongPtr is identical to Long in 32 bit. In any case; while it would be prudent to switch to LongPtr for handles, window handles will always fit into 32 bit integer variables as long as 32bit applications are supported in Windows so the SendMessage call should still work even with HWND being a regular long. I doubt that's the issue here.
  1. Helpful
Andreas Mykonios
  1. Andreas Mykonios
  2. Tuesday, 21 November 2023 13:30 PM UTC
Yes. But here it seems that the choice of the value a variable should take is different... Tooltip.cbsize = 64 for x64 and Tooltip.cbsize = 40 for x32 etc.

Andreas.
  1. Helpful
Benjamin Gaesslein
  1. Benjamin Gaesslein
  2. Tuesday, 21 November 2023 14:00 PM UTC
Yes, the cbsize member must always contain the size of its parent structure in bytes. The datatypes used within the tooltip struct are more likely to cause an issue here.
  1. Helpful
There are no comments made yet.
Subrat patra
Subrat patra Accepted Answer Pending Moderation
  1. Tuesday, 21 November 2023 13:06 PM UTC
  2. PowerBuilder
  3. # 2

Hi Miguel,

Thanks for the response.

Please find the screenshot of the function. Do I need to change the long to longptr?

 

 

Regards

Subrat

Comment
Arnd Schmidt
  1. Arnd Schmidt
  2. Tuesday, 21 November 2023 13:14 PM UTC
You need to change a lot... still using ANSI?! .. including your memory copy art :-(

  1. Helpful
Subrat patra
  1. Subrat patra
  2. Tuesday, 21 November 2023 13:19 PM UTC
Hi Arnd,



yes !!!.

Can you suggest what are the things i need to change/follow ?



Thanks

Subrat
  1. Helpful
Benjamin Gaesslein
  1. Benjamin Gaesslein
  2. Tuesday, 21 November 2023 14:05 PM UTC
Check the definition of the toolinfo structure, you might have to use LongPtr for any handles in there.
  1. Helpful
There are no comments made yet.
Andreas Mykonios
Andreas Mykonios Accepted Answer Pending Moderation
  1. Tuesday, 21 November 2023 13:27 PM UTC
  2. PowerBuilder
  3. # 3

For start, where you see an argument starting with h (hWnd) this probably is a handle, and yes it should be changed to longptr. MemHandle in LocalFree is also a handle (LocalFree function (winbase.h) - Win32 apps | Microsoft Learn). So it should be a longptr.

Andreas.

Comment
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 21 November 2023 15:02 PM UTC
  2. PowerBuilder
  3. # 4

Hi Subrat;

  I added PowerTipText feature that you see natively in the DataWindow built-in to PB to all visual objects in the PB System Class in my STD Framework release 2022R1.   http://chrispollach.blogspot.com/2022/03/stdfc.html

   You can see how it's implemented in that framework release (or higher) in the source code. The framework is free & open source, so please grab any code that you need to implement this in your App (s). The nice thing about this implementation is that I did not use any SDK calls, so it works in either 32 or 64 bit mode. Plus, I have now tested this in PB2022R3 and even in the PB2025 pre-Alpha build that I used for my demo in Elevate 2023 conference. This approach all works great.  ;-)

    So this might be another option if you cannot get your approach to work. HTH

PS: Also, it's multilingual ready & requires no coding by the PB Programmer to use.  ;-)

Regards ... Chris

Comment
There are no comments made yet.
Bruce Armstrong
Bruce Armstrong Accepted Answer Pending Moderation
  1. Tuesday, 21 November 2023 20:11 PM UTC
  2. PowerBuilder
  3. # 5

For the record, to the best of my knowledge the PFC does *not* have a reference to the ToolTipMsg API call.  There is an add on service for datawindow tooltips written by Philip Salagannik that does.  We incorporated it into our corporate extension layer and I believe we gave our source code to Appeon (or SAP back in the day) so that may be where Appeon had the impression that it's part of PFC.

My first recommendation to you, provided this is the same code we're talking about, is searching for of_settooltip(TRUE) in your application.  If you can't find that, then you're not using the service and instead of wasting time migrating something you're not using I would suggest stripping it out instead.

Support for tooltips in DataWindow columns was added as a native feature in PowerBuilder 11.5.  I can't see any reason why you would want to continue to use the add on service at this point anyway.

 

Comment
There are no comments made yet.
Subrat patra
Subrat patra Accepted Answer Pending Moderation
  1. Wednesday, 29 November 2023 11:43 AM UTC
  2. PowerBuilder
  3. # 6

Thanks.Its worked :)

Comment
There are no comments made yet.
Subrat patra
Subrat patra Accepted Answer Pending Moderation
  1. Wednesday, 29 November 2023 11:44 AM UTC
  2. PowerBuilder
  3. # 7

Thanks. Its working fine now.

Comment
There are no comments made yet.
Pieter Coene
Pieter Coene Accepted Answer Pending Moderation
  1. Friday, 7 June 2024 11:02 AM UTC
  2. PowerBuilder
  3. # 8

Hi Subrat,

what did you end up changing? I had exaclty the same behaviour. It worked on x32 but we are testing to migrate to x64. So i changes the cbSize to 64 (only when in x64 bitness). Refactored the external functions to work for x64 and now the ToolTipMsg command just crashes my application.

There must be something i forgot to change, but can't think of anythng.

Greetz
Pieter

 

Comment
Load more comments
John Fauss
  1. John Fauss
  2. Friday, 7 June 2024 15:09 PM UTC
@Pieter - The difficulties you've been experiencing are caused by improper data type assignments in the structure(s).

The reasons why the value assigned to the cbSize member of the ToolInfo structure has to increase when migrating to 64-bit are:

(1) Handles (such as the "hwnd" member) are now 64-bit integers EVEN THOUGH THEY CONTAIN 32-bit VALUES. This is why I wish people would STOP suggesting it is OK to continue using Long/ULong data types for values that contain Windows Handles. This drives me bonkers (and yes, it is a short trip since I'm frequently accused of being halfway there most of the time). Everyone, please just stop doing this.

(2) Arguments passed by reference are memory addresses, so these now become 64-bit values. The PB compiler takes care of this.

(3) 64-bit integers must begin on a memory address that is evenly divisible by 8, so some padding between members may be needed in 64-bit that was not needed in 32-bit. The PB compiler also takes care of this.

(4) The total length of a structure in memory must be evenly divisible by 8 in 64-bit, so some padding at the end of a structure may be needed in 64-bit that was not needed in 32-bit. The PB compiler also handles this for you.

If you identify the structure members that need to be 64-bits in length and use the Longptr data type for these members and assign the correct structure size based on the app/process bitness, the API functions will work correctly.

Admittedly, sometimes it is not easy to determine if the data type of a structure member should be changed to Longptr because of the nested typedef's that are used throughout the Windows API. The URL below is one that I frequently use to help me determine the proper PB data type(s) to use:

https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types

If the type definition isn't listed in this web page, I search the header files (*.h) in the Windows API libraries that are installed with the (free) community editions of Visual Studio. The information is available... sometimes you just have to dig a little to find it.
  1. Helpful 1
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Friday, 7 June 2024 16:13 PM UTC
Hi Pieter;

FYI: I just released an updated version of the PB based Windows Explorer application last night ...

http://chrispollach.blogspot.com/2024/06/explorer.html

Regards ... Chris
  1. Helpful
Pieter Coene
  1. Pieter Coene
  2. Monday, 10 June 2024 06:24 AM UTC
Thx John and Chris,



@John: i'll double check all the structures and handles again ;)

@Chris: i did not knew this one, i'll take a look into it!



Greetz

Pieter

  1. Helpful
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.