Examples of WinAPI usage needed

[caa]

All,

We're starting a project to address compatibility of WinAPI function calls with TD 5.1. Our primary focus is on menuing, since the majority of discussion that we've seen about WinAPI seems to center around menuing. However, if you're using other features, we'd like to see those as well.

We'd like to get example applications of how our customers are using WinAPI in TD, so that we can be sure to address the correct functionality.

Preferably, these should be small, compilable, and runnable examples that are designed to show us how you're using WinAPI. The less setup required, the better.

Since we're running on a deadline, we'll be accepting these for the next two weeks: our last day will be by close of business January 25th. Please just attach the samples to this thread, or private message me if it's too large to do so. We'll make alternative arrangements.

Thanks in advance!

[Jeff Luther]

Hopefully you will be flooded with replies!, but until the attachments start flowing in, how about going to the gupta newsgroup at newsgroup.guptaworldwide.com and look in the source and programming sections for samples. There should be all kinds of examples posted over the years.

Additionally, the WinAPI and SALExtension zips on my web page in the samples section show the kinds of things people are and have been doing. Here too are some links with samples:

Dave R.: http://guptateamdeveloper.wiki.xs4all.n ... =Main_Page
Christian S.: http://www.cschubert.net/html/tools___samples.html
Narod: http://gupta.narod.ru/archive.html
Narod's links to other sites: http://gupta.narod.ru/links.html
Lubos V: http://sqlweb.vnuk.org/gup/index.html
Thomas W.: http://www.twiedmann.de/gupta/Centura

If TD can (and it should) support an interface to 3rd-party DLLs, then the Win API is only another series of '3rd-party' DLLs masquerading as the O/S!

I'm sure hoping too that the implementation won't be a short laundry-list subset of API functionality:"You can make this call, but you cannot call that." Being able to trap and process most any WM_xxx msg, the U/I stuff in USER32, system/under-the-covers stuff in KERNEL32, graphics in GDI32, + SYSTEM, COMM, should all be included. And I know that isn't the entire list.

One of the BIG features of TD, waaay back to SQLWindows v1 released Sept. 1988, was its extensibility for declaring/using outside DLLs and the Win API. If that gets chopped off or radically curtailed that is going to be a big blow to the feature set of the TD product, and puts a large additional burden on Unify development to incorporate those 'outside' features into the product itself. Frankly, it can't be done. (That would be like trying to put everything into one book!)

But let me end on a positive note... If you want some chunks of code, email me personally -- so we don't clog up this forum with bunches of misc. zip attachments -- and I can zip and email you some stuff I've collected over the years for v4.2 and earlier. I certainly haven't tested nor used much/most of this code, but I'm sure I have megs of API (and ActiveX) samples going back to the early 2000's, stuff I've downloaded right off the gupta NG.

[Dave Rabelink]

One of the BIG features of TD, waaay back to SQLWindows v1 released Sept. 1988, was its extensibility for declaring/using outside DLLs and the Win API. If that gets chopped off or radically curtailed that is going to be a big blow to the feature set of the TD product, and puts a large additional burden on Unify development to incorporate those 'outside' features into the product itself. Frankly, it can't be done. (That would be like trying to put everything into one book!)

Completely true !

The "open" environment TD offered us in previous versions concerning 3rd party functionality (the WinApi is one of them) gave developers a way to implement not native solutions to their products, which gave them a way to keep up with the rest of the world. TD was keeping behind the new features and by additional custom coding this was primarily not a show stopper (at least for us here).

As expected for new versions, there should be more compatibility and more integrated features, not less.
So I'm pleased Unify addresses this by focussing on this issue.

As for the WinApi usage in TD, best way to look at it is to make TD5.x compatible with the WinApi32.apl which is widely used. It contains numerous API functions which in fact are used and should be able to be used in newer TD versions. But as can be seen in that library, it contains a lot. And that is not all of it, there are many more features used from WinApi. Additional there are many other 3rd party API's from other vendors.
When I look at the WinApi at our build applications, it is a very large list.

I will look into the most important ones and I try to get some posted here (working in TD51 or not). Problem is it is time consuming to produce small samples, which I do not have alot.

It is true the problems with menu WinAPI functionality is a pain for starters.

Dave

[Dave Rabelink]

We'd like to get example applications of how our customers are using WinAPI in TD, so that we can be sure to address the correct functionality.

For clarity, do you need *any* WinApi usage or only the ones which fail in TD51 ?
Do you want the samples in TD51 or do you need samples in prior TD versions which work/fail in TD51 ?

For example, I could imagine the A versions of WinApi functions should be rewritten to use the W versions, as TD51 is UNICODE.
Without the conversion to W, samples ported to TD51 could fail but could work when the W versions are used.
(I recon when the A version works in TD versions prior to TD51, the W versions should work in TD51)

I think the most problems with WinApi we have are the ones which are conflicting with the new layer of the ProfUI API. So functions which change or enhance
GUI objects/windows.

A suggestion :

The community has build many WinApi declarations and they are put into common used libraries like WinApi32.apl (as mentioned in my previous post). This is a real addition to the toolset of TD. Using new API functions in projects is just searching in the library for the declaration and because it is present in the library, others have used it and should work when integrated and called properly.

http://www.xs4all.nl/~dapjr/TD/Samples/winapi32.zip

I would like to see a WinApi32_TD51 library, where all working WinApi calls are put. Having such a library helps developers getting the right declaration and gives them a clue the API function should work. Personally, I dislike to invent the wheel for the x'th time, so if I have a reference to a set of working Api declarations I would be very pleased.

I believe TD should offer such a library out of the box, officially supported. Just like SalExtension and the 'old' WinApi32 library is a growing library set (maintained by the community), I could imagine having Unify and the community working together to put such libraries together for TD5.x.
It should be available on the Unify Website as a download add-on which is updated by Unify regularly based on input from the community and internal Unify developers.

Advantage of this is developers have a central library which contains correct declarations. When they need a specific function, they can download the latest version of the library and use it. They know the function is working as it is part of the library and is sure the declaration is right. When not present in the library, the developer can try to declare and create samples on their own. When it works, they could send a sample to Unify (or post it on the Unify forums).
Later this is added, when checked, to the library so others can benefit from it.
When functions are not working due to compatibility problems, Unify can try to fix it. Known not-working functions can be added to the library indicating that the function does not work (so the developer knows and does not spend valuable time to get it working). Also additional info can be placed in the library, workaround info or other useful stuff.

This saves developers valuable time, but also Unify benefits from it. Developers will post less declaration problems in the forums (they use WinApi declarations from the library).

WinApi is very large and it is impossible to get it all present as declarations in a Win32 library. But the library should be a growing library, starting with just a few, the most used functions and in time it grows to a set just like WinApi32.apl.


Here I provide a small example of a WinApi32_TD5 library and two testcases using it.
(The TopMost sample shows a workaround implementation from the common WinApi32 library)

Dave

[TPo]

Hi!

Here's a small test apt I would like to see working at TD 5.1.
Works fine with TD 3.1.

Creates dynamic menus to MDI window.

regards

Teuvo

[Dave Rabelink]

Here a sample to fill a buffer with strings (using SAL, cstruct and heapmemory WinApi).

WinApi functions used :

- GetProcessHeap
- HeapAlloc
- memcpy
- RtlMoveMemory
- HeapFree
- RtlFillMemory

(Sample crashes in TD51 on the WinApi part, works in prior TD versions, but that's probably caused by inproper UNICODE buffer allocations)

WinApi is way faster than SAL or cstruct, that's the reason we use it in our projects to fill huge memory buffers.

Dave

[caa]

Hopefully you will be flooded with replies!, but until the attachments start flowing in, how about going to the gupta newsgroup at newsgroup.guptaworldwide.com and look in the source and programming sections for samples. There should be all kinds of examples posted over the years.

While I appreciate the links, and we'll definitely look at those samples, I'm more interested in what customers are using right now, today, in their production applications. We're hearing that lack of WinAPI compatibility is stopping migration from previous versions to TD 5.1. Therefore, we'd like to see the specifics on what's stopping migration so that we can come up with a method of resolving those problems.

[caa]

We'd like to get example applications of how our customers are using WinAPI in TD, so that we can be sure to address the correct functionality.

For clarity, do you need *any* WinApi usage or only the ones which fail in TD51 ?
Do you want the samples in TD51 or do you need samples in prior TD versions which work/fail in TD51 ?

For example, I could imagine the A versions of WinApi functions should be rewritten to use the W versions, as TD51 is UNICODE.
Without the conversion to W, samples ported to TD51 could fail but could work when the W versions are used.
(I recon when the A version works in TD versions prior to TD51, the W versions should work in TD51)

I think the most problems with WinApi we have are the ones which are conflicting with the new layer of the ProfUI API. So functions which change or enhance
GUI objects/windows.

I think you're right about the conflicts with ProfUI. What I'm looking for are examples of specific functionality that are stopping customers from migrating from a previous release to TD 5.1. If, for example, using the W functions allow you to move to TD 5.1, then that's less interesting than something in your app that doesn't work at all, with no route forward.

Does that make more sense?

I'll pass your comments about how to package our results on to the developers.

[Jeff Luther]

In the interest of helping out with Chris' request, plus maybe giving others here a few API samples they might not have otherwise, I've put together a x-section of some self-contained code using the API. These all run in v4.2 (and most/all are in v4.2, so if you have an earlier version instead, click on my link below and get my TD-Convert utility). These are only a small subset, but hopefully are 'generic' enough to show that v5.1 needs to be able to handle a number of different DLLs in the API.

Elsewhere, I provided some links to other places with samples. And support Dave and others in saying that SALExtension.ZIP, WINAPI32.ZIP, Michael's MTBL/MIMG code ( http://www.micsto.com/ ) should also be on the 'must have' list.

[Dave Rabelink]

We use the function SetThemeAppProperties from UxTheme.dll to disable the theme painting.

Unfortunately TD5 does not (yet) support to force classic theme on applications.
(or I did not find it yet )

In TD5, the API function does not work.


Dave

[jmccall]

I think you're right about the conflicts with ProfUI. What I'm looking for are examples of specific functionality that are stopping customers from migrating from a previous release to TD 5.1. If, for example, using the W functions allow you to move to TD 5.1, then that's less interesting than something in your app that doesn't work at all, with no route forward.

Does that make more sense?

It makes sense in words ... but there's a small flaw in the logic, at least in my case. As is well documented by now the Windows API for menus doesn't work. Having spent best part of a week porting my main SQL Windows application to TD5.1 (eval) it compiles but I can't run it ... IT DOESN'T HAVE ANY MENUS!

Give my application its menus back and I'll be able to let you know what else doesn't work.

... or offer me a discount on my upgrade and I'll spend time writing some test apps for the other external APIs I use, veryify whether or not they work

James McCall

[caa]

It makes sense in words ... but there's a small flaw in the logic, at least in my case. As is well documented by now the Windows API for menus doesn't work. Having spent best part of a week porting my main SQL Windows application to TD5.1 (eval) it compiles but I can't run it ... IT DOESN'T HAVE ANY MENUS!

Yes, we're aware of the problems with menuing. Examples of conflicts there would help as well.

Thanks!

[Jeff Luther]

Chris: I'll attach a v51 version of my menudemo32 sample on my code page, FYI. Basically, none of the Win API menu calls work.
(Sample does a couple silly things - show/hide, rename, etc. and works in v42 and earlier.)

I figured you likely had some samples already, but since you've made a request for menu tests that fail I'll submit this to you.

[jmccall]

It's been a while so can anybody now tell us whether or not the WinAPI problems introduced by the use of ProfUI are fixable? And if so, when we might get a TD5.x version containing the fixes? Even if you can only tell us to the nearest quarter or even the nearest year at least we can make contingency plans.

If they are not fixable, what chance of getting Unicode support retrofitted to a previous version of TD?! It's the only thing I need out of this upgrade and I've been waiting for it since CTD2000!

Thanks,
James McCall

[caa]

James,

We're doing our best to fix the ones raised here for Service Pack 2. We think that we've got every test case that's been submitted in response to this request working, but we're still testing.

We have no plans to retrofit Unicode support to TD 4.2 at this time.