API calls make application prone to crash

[Guus2005]

Looking for a message box replacement i found one that looks very nice and is extremely flexible.
It uses a lot of API Calls and in my experience having a lot of API Calls makes an application less robust. It crashes a lot and sometimes even corrupts the database.
I must say that that is not my experience with this particular piece of code. It is my experience in general. Before i add this piece of code to my project, which when deployed will be used around the world, i wanted to know what your experience is in that area.

Thanks!

 

[Ranman256]

Access provides MSGBOX. It is very simple to use.
To skip the API, just make a form, set it to dialog,and put a label on to provide the
Message to the user.

 

[Guus2005]

Hi Ranman256, not sure if you're being sarcastic...
But thank you for your answer however, my question was about your experience with windows api's and not another alternative for the msgbox.

 

[The_Doc_Man]

I have used a couple of direct Windows API calls, mostly for window sizing and placement as a way to further annoy my users by not letting them see the Navigation pane because my switchboard was always in the way. I have played with the high-precision timer functions a few times. I also used a printer function once or twice. None of the calls have caused me any problems once I learned how to give them the data structures they required, and I have found that part to be supremely important as well as eminently possible. You DO have to be careful about things the WIN API manuals refer to as "handles" (has to be WORD) and as addresses (has to be LONG) because their sizing is incredibly important.

For the most part, I have not found the need to use direct API calls because I have not done that much to require such a call. However, I might also suggest that you are looking at it the wrong way.

When you make a reference to the DAO or Windows Scripting libraries, you ARE making API calls in the technical sense. Just because you are not calling MAPI functions or something else that has API in the name doesn't mean that it is not a call to an Applications Program Interface. If there is any instability to be had it will be due to the way you implement the call. The things you call from an "xxAPI" are no more unstable than the DAO, ADO, Word, Excel, or Outlook libraries.

 

[Guus2005]

Hi The_Doc_Man,
I am aware that API calls are used even when i don't specify them explicitly. Perhaps handles or addresses were dimensioned wrong. I have to look into that.

Thanks for your input.

 

[CJ_London]

I presume you are aware of the differences you need to account for between 32bit access and 64bit.

I use 'VBA' API calls frequently (mainly from the user32 dll) and have never had an issue with crashing (subject to correct coding). Calling web based ones relating to say google or amazon do need some extra protection around them because of timing delays or no response.

When you say crashes, what does that imply - freezes? drops out? you get an error message? If the latter is it always the same message? does it happen anywhere, anytime?

 

[Rx_]

Used a lot of API calls in my last environment.
As said, it is necessary to check for 32/64 bit.

The biggest problem comes into the testing of them across various platforms.
Some of my API calls that worked great on the desktop, just would not work on Windows Servers for example.
Since you are offering to run these with diverse customers, testing is important.
The first option would most likely be to get a copy of Windows 10 Pro and run applications in various backward compatibility modes.
Or, set up a VM and install various Windows OS and Office versions.
Also of importance: I have several post about using SQL Server Native Client for ODBC rather than the built in ODBC that is installed on a OS.
Especially if your products use Azure. SQL Server Native Client is free.

I eventually solved all the problems by using Citrix at the last contract.
Citrix let me program once, test on my desktop development OS, then test once on Windows Server OS.
Currently, I am logging in 50 hours a week at the present assignment.
Again, those free Citrix small business seminars are during working hours.
It appears that Citrix has new low cost services for a small business operation.
My neighbor offers a cost-effective "competitor" to Citrix.
Citrix allows Access to run on any platform, reduces all of the messy registry issues for each platform / OS / Office version. As an ASP, its bandwidth is a fraction of any HTML based system. Plus, it delivers the rich user interface just like your desktop version.

My advice for a commercial product would be to weigh the total cost of maintenance vs the cost of deploying your product using Citrix with an AZURE cloud service.

 

[Guus2005]

Hi CJ_London, Rx_

When i say crashes i mean that you get thrown out of access with no message at all. And removing the dll calls solved my problems. That was a few years back.
Yes i used compiler constants to determine the Windows environment 32/64.

When i switch from form design mode to the IDE in a the above example i get Access is "not responding" for a few seconds. This happens only the first time.

I must say, again, crashes didn't occur in this example but i am a little reluctant sending this application around the globe.

Thanks for your input!

 

[Rx_]

Don't be discouraged by using API.
Just go to the extra effort of creating documentation for test plans to test, test, test the API. Document the OS and Office versions they were tested on.

You might even go so far as to create a really simplistic application that does nothing more than test each API and report the results with some kind of pass/fail. A kind of Compatibility Checker for your clients.

The first time I came up with Citrix was as a CTO for a small medical care company. The remote support and maintenance was sinking the company.
Then, I came up with a Citrix solution. All the problems just vanished as the $3M ($9M in today's money) of VB 5/6, Access, SQL Server and Excel product for medical plan of care was really good.
It was all the remote maintenance that nearly sank the company.

API can be very powerful. But, they can be difficult to remotely support across PC with little or no configuration management.

 

[Ranman256]

Sorry,misunderstood.

 

[Guus2005]

Sorry,misunderstood.

No worries.