🚀 go-pugleaf

Put this function prototype at the top of your file immediately after the 
includes.

__declspec(dllimport)
extern "C"
void __stdcall Sleep(unsigned long millisec);

.  Ed

> Andre Steenveld wrote in message
> news:46f01013@newsgroups.borland.com...
>
> I've a problem with a console application and the Sleep() api call.
>
> What I need/want, in some states of the program, is to release the 
> timeslice in a console application while it is waiting on (non blocking) 
> user input. For that I need access to usleep(msec) or Sleep(msec). A call 
> to sleep(sec) is not realy an option. Users will notice a delay of one 
> second most certenly.
>
> The alternative is to do busy-waiting and keep the processor load at 100%. 
> Not a nice option.
> Another alternatice is to switch between blocking and non-blocking input 
> which doesn't sound atractive to me. (more code prone to buggy behaviour)
>
> Since the application is a console application I can't include 
> <windows.h>. If I do, a load of compile errors is the result.
> But to use sleep(), usleep() or Sleep() I must include <windows.h> 
> according to the documentation.
>
> Does someone know how to call a windows API call from a console 
> application? Does someone have a suggestion to tackle this problem?

"Andre Steenveld" <a.steenveld@id.umcn.nl> wrote in message 
news:46f01013@newsgroups.borland.com...
> Hi,
>
> I've a problem with a console application and the Sleep() api call.
>
...snip...
>
> Since the application is a console application I can't include 
> <windows.h>. If I do, a load of compile errors is the result.

Ed already told you how to address your issue.

But, FWIW, it is possible to build a console application that includes 
windows.h.  Whatever your compile errors are when you include windows.h, 
they are not likely caused specifically by a console application including 
windows.h.

I occasionally write small console appls that include windows.h to test 
something specific, and they (eventually) build and run without error.

"Andre Steenveld" <a.steenveld@id.umcn.nl> wrote in message
news:46f01013@newsgroups.borland.com...

> Since the application is a console application I can't include
<windows.h>.

Yes, you can.  Console apps have full access to the Win32 API, as they are
Win32 processes to begin with.  There is no such thing as true DOS in
Windows anymore.  A console window is a 32-bit process that simply mimics
the DOS environment so old DOS apps can still run.  But being a true 32-bit
process, the Win32 DLLs are available for console apps to use if they want
to.

> If I do, a load of compile errors is the result.

Then you did not set up your project correctly to begin with.  Did you use
the Console Application wizard when you created the project?

> Does someone know how to call a windows API call from a console
application?

Just call it.  It works fine in console projects.


Gambit

Ed,

> __declspec(dllimport)
> extern "C"
> void __stdcall Sleep(unsigned long millisec);

Almost did the trick. I had to use `extern' in stead of  `extern "C"'. 
Afther that there were no more problems.
Just thinking how you got the information. Did you catch the preprocessor 
output? Maybe I can use that trick the next time too.

Thanks.

Andre Steenveld.

Hi Gambit,

>> Since the application is a console application I can't include
> <windows.h>.
>
> Yes, you can.  Console apps have full access to the Win32 API, as they are
> Win32 processes to begin with.  There is no such thing as true DOS in
> Windows anymore.
...
You are of cause right but I just realise it too late. As I said in a 
previous message, this implies another problem that I need to check. Thanks 
for the advise.

Kind regards,

Andre Steenveld.

Hi,

> ...snip...
>>
>> Since the application is a console application I can't include 
>> <windows.h>. If I do, a load of compile errors is the result.
>
> Ed already told you how to address your issue.
And he was right.

> But, FWIW, it is possible to build a console application that includes 
> windows.h.  Whatever your compile errors are when you include windows.h, 
> they are not likely caused specifically by a console application including 
> windows.h.

Thanks for the advice. I've build a few console applications myself but
never had the need to use <windows.h>. Your sugesting that there is another
problem with my code. I need to check that out.

Kind regards,

Andre Steenveld.