1. John Fauss
  2. PowerBuilder
  3. Friday, 20 September 2019 22:02 PM UTC

Does anyone know how to call a Windows API function that is defined within a Windows Interface from PowerBuilder?

Specifically, I'm trying to call the ITaskbarList3::SetOverlayIcon API. The normal WinAPI strategy of defining a local external function definition does not work. It compiles, but receives Application Error R0015 "Error calling external function SetOverlayIcon at line nnn in clicked event of object cb_test of w_main." at execution time.

I'm pretty confident I have the proper datatypes for the 3 parameters and valid values, so I suspect this wrinkle of the API being defined as part of an interface is causing the issue.

I'm using PB 2017 R2 Build 1769 on a Windows 7 Ultimate (64-bit) O/S.

TIA,
John Fauss

Roland Smith Accepted Answer Pending Moderation
  1. Saturday, 21 September 2019 02:16 AM UTC
  2. PowerBuilder
  3. # 1

This example shows how to display icons in the system icon tray and display notification messages.

http://www.topwizprogramming.com/freecode_icontray.html

Instead of overlaying the icon, you can completely swap out the icon.

Comment
  1. John Fauss
  2. Saturday, 21 September 2019 04:34 AM UTC
That's a good suggestion for an alternative approach, Roland, and I will look at it. Thank you!



I'd still like to figure out a solution to the original question, however...partly because I'd simply like to know how to do it, and partly because this API provides exactly what I would like to accomplish. I may have to try to invoke it from .NET using a COM-callable wrapper? Never done that before, but I know there are examples around.
  1. Helpful
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Saturday, 21 September 2019 11:31 AM UTC
  2. PowerBuilder
  3. # 2

Hi John,

Calling win32 API functions is pretty straightforward. Declare (local) external function. Create wrapper PowerScript function to ease doing actual win API call. Pre-allocate space for REF strings. Other fun stuff like mapping data types correctly to win32 (docs often have C examples).

However, if you need to call .NET API you have to manage win32 <=> .NET interop. Hence, typically COM callable wrapper and some C# class + method doing actual API calls.

On horizon in PB road map is easier interop PowerScript <=> .NET. But remember road map means not current release means not of help right now in front of your screen + keyboard.

Roland's TopWiz website has plethora of free examples demonstrating how to leverage windows API calls from PowerScript. Wrapping details in PowerScript functions in specific NVOs - meaning good code design easy to migrate into your existing code port folio.

HTH /Michael

Comment
  1. John Fauss
  2. Sunday, 22 September 2019 19:48 PM UTC
Hi, Michael -



I've got adequate experience in creating/using local external function declarations to invoke Windows API functions. The free code examples Roland generously provides to the PB community on his TopWizProgramming website are excellent and I have learned greatly from them over the years.



The Windows API documentation online lists the topics for "normal" API functions such as "LoadIconW" in a manner different than API functions which appear to be accessible only via an interface: "LoadIconW function" vs "ITaskbarList3::SetOverlayIcon", for example, and this distinction appears to be critical, else why would Microsoft document them differently?



There are a considerable number of existing WinAPI functions that are defined only as part of an interface, and I would like to learn how to call such interface functions from PB and share that knowledge with the PB community so that we can all benefit. I was hoping that someone had already blazed that trail, but If no one knows, I'll figure it out eventually.
  1. Helpful
  1. Michael Kramer
  2. Sunday, 22 September 2019 21:08 PM UTC
Hi John, Me too on Win API and Roland's goodies!

You may see additional replies Monday as people return from weekend.

I believe we see Microsoft develops new O/S features as object classes and therefore interfaces.Consequence: We need object interop instead of just calling functions in DLLs.

PBNI is the rescue when writing such object interop in C++.

Another option soon is .NET interop in PowerScript without COM callable wrappers. Nice!
  1. Helpful
  1. John Fauss
  2. Tuesday, 24 September 2019 02:52 AM UTC
Hi, Michael - I appreciate your input. PBNI does appear to be the way to go, for now at least.
  1. Helpful
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Saturday, 21 September 2019 18:35 PM UTC
  2. PowerBuilder
  3. # 3

 

This isn't a .Net API. Someone who is a C++ expert could create a PBNI extension to allow using it from PowerBuilder.

I have been doing a lot with PBNI recently but my C++ is still at the beginner level.

This might be helpful:

https://www.codeproject.com/articles/42345/windows-7-goodies-in-c-taskbar-progress-and-status

 

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 23 September 2019 14:12 PM UTC
  2. PowerBuilder
  3. # 4

Hi John;

  While some WinAPI's can look straight forward, others can require significant coding in order to work properly. Some API commands also have various calling argument combinations. Some same commands even can have different return values. Then you also have the difference between ANSI=>Unicode, & 32bit=>64bit commands as well.

   I use a plethora of WinAPI SDK calls in my free STD framework and they are located conveniently in one object ...  the "nc_app_controller_master" object class within the "STD_Base.pbl" library. If you download my framework and review this object's source, you can see all the external declarations for both Functions & Subroutines as well as most of the calling code that utilizes these commands. These commands have been designed to work in both Native PB and PowerServer Web applications. Other NVO classes will also typically use the external definitions by using the calling convention:  go_ac.ExternalCommand(). Where the "go_ac" always points to the App's current "Application Controller".

HTH

Regards ... Chris

Comment
  1. Roland Smith
  2. Monday, 23 September 2019 14:59 PM UTC
The function he is looking at is a C++ Interface, not a standard Win32 API function that can be called directly from PB.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Monday, 23 September 2019 15:13 PM UTC
In that case, one might need to write a C++ interface DLL to handshake between PB & the C++ code as PB requires PASCAL calling conventions. Also if "callback" support is required as well.
  1. Helpful
  1. Roland Smith
  2. Monday, 23 September 2019 17:41 PM UTC
Perfect use case for a PBNI extension.
  1. Helpful
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 24 September 2019 02:48 AM UTC
  2. PowerBuilder
  3. # 5

Chris - Thank you for responding. I can handle the function declarations for "normal" API functions OK, but API functions that are defined as methods within an interface appear to be a completely different animal. Roland, thank you also for your responses. It does appear that, in general, PBNI may be the best tool to use to access WinAPI functions that are part of C++ interfaces.

That's new territory for me, but I like technical challenges, so it might be time to learn how to create PBNI extensions.

Ideally, it would be great if PB were enhanced to work native with WinAPI Interface methods. I've recently seen example code written in Delphi that can do this and I'm sure there are other languages that support this capability. Since PB is translated into C++ code, it seems like a logical progression for an enhancement that would open a significant portion of the complete Windows API to PB.

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.