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.

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

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

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

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.