Solved

using CreateWaitableTimer in Non-MFC Code?

Posted on 1998-01-15
5
640 Views
Last Modified: 2008-02-01
I am trying to include the function CreateWaitableTimer() and its associated functions into a 'C' program, that otherwise doesn't have anything to do with Windows or MFC.

It says to #include <winbase.h>. I did this. I then tried to compile it but got errors about DWORD. I found the definition of DWORD in windef.h, but then got errors in winnt.h about "winnt.h(2057) syntax error: identifier 'PCONTEXT' ". Well, PCONTEXT is defined above that in the same file.hhmmmmmm.

Anyway, it looks like I could spend days adding #include files into my file just to use this function, and getting them in the proper order. Can anyone help me use this function? What do I need to #include? Then comes the question of what libs I need to link with.....

Thanks,

Tom
0
Comment
Question by:gunn
5 Comments
 
LVL 32

Accepted Solution

by:
jhance earned 70 total points
ID: 1178372
CreateWaitableTimer is a Win32 API function (NT only by the way) and it's defined in winbase.h.  If you include that as well as windows.h, you should have all you need.  Be sure to link with kernel32.lib.  This function is not MFC but certainly requires a 32-bit compiler.  You didn't mention your environment, if you're not using a compiler which supports NT, then you can't use this function.
0
 
LVL 15

Expert Comment

by:Tommy Hui
ID: 1178373
thanks for the quick response. Your answer is correct in that including windows.h did the trick (found that out shortly after the question...hehe).

Anyway, forgot to mention about the environment. I'm running WindowsNT4.0 w/ Service Pack 3, and the MSVisualC++ 5.0 compiler.

Heres my new problem with this function: I'm getting a 'CreateWaitableTimer' undefined: assuming extern returning int'
message. I went through winbase.h and found that there is a preprocessor definition #if( _WIN32_WINNT >= 0x0400 ) around the  prototype of the functions I need.  It seems to be not true as I would think.  Why is this not true in my case???


0
 

Author Comment

by:gunn
ID: 1178374
man, you guys are fast in your responses. before I could finish typing out the comment above about the problem, thui had answered my question!! It works fine now...thanks guys.
0
 

Author Comment

by:gunn
ID: 1178375
THE FOLLOWING IS FROM MSDN
Article Id : Q167799
Last Reviewed: March 31, 1998
Section 3 - Header File Conventions

In the header files, information guarded by


    #if _WIN32_WINNT >= 0x0400

is implemented only in Windows NT version 4.0 and later.
It is not implemented in Windows 95.
This precompiler guard allows you to do compile- time checking for platform differences.
The value of _WIN32_WINNT is set in WIN32.MAK, depending on the platform you choose to target.
By default, WIN32.MAK now sets the TARGETOS to WINNT and the APPVER to 4.0.
As a result, by default, _WIN32_WINNT is now defined as 0x0400.

If you are building an application to run on Windows 95 and you want compile-time notification of compatibility issues,
set TARGETOS=BOTH in your makefile.
When TARGETOS is defined as BOTH, _WIN32_WINNT is not defined for the precompiler,
and the only information parsed at compile time will be applicable to both Windows 95 and Windows NT.

If you do not include WIN32.MAK in your makefile,
you need to explicitly define _WIN32_WINNT as 0x0400 to get some of the new Windows NT 4.0- specific material from the header files.

There are several API sets present in Windows 95,
OEM Service Release 2 that are still guarded by (_WIN32_WINNT >= 0x0400),
e.g. the Cryptography API. If you are writing an application specifically for Windows 95,
OEM Service Release 2, and you want the header files to provide compile time access to these APIs,
it is necessary to define _WIN32_WINNT as 0x0400.
Notice that an application that uses these technologies will not run correctly on the retail release of Windows 95.
The vast majority of application programs that are expected to run on Windows 95 should be built without defining _WIN32_WINNT.


0
 

Expert Comment

by:bhovan
ID: 1178376
THE FOLLOWING IS FROM MSDN
Article Id : Q167799
Last Reviewed: March 31, 1998
Section 3 - Header File Conventions

In the header files, information guarded by


    #if _WIN32_WINNT >= 0x0400

is implemented only in Windows NT version 4.0 and later.
It is not implemented in Windows 95.
This precompiler guard allows you to do compile- time checking for platform differences.
The value of _WIN32_WINNT is set in WIN32.MAK, depending on the platform you choose to target.
By default, WIN32.MAK now sets the TARGETOS to WINNT and the APPVER to 4.0.
As a result, by default, _WIN32_WINNT is now defined as 0x0400.

If you are building an application to run on Windows 95 and you want compile-time notification of compatibility issues,
set TARGETOS=BOTH in your makefile.
When TARGETOS is defined as BOTH, _WIN32_WINNT is not defined for the precompiler,
and the only information parsed at compile time will be applicable to both Windows 95 and Windows NT.

If you do not include WIN32.MAK in your makefile,
you need to explicitly define _WIN32_WINNT as 0x0400 to get some of the new Windows NT 4.0- specific material from the header files.

There are several API sets present in Windows 95,
OEM Service Release 2 that are still guarded by (_WIN32_WINNT >= 0x0400),
e.g. the Cryptography API. If you are writing an application specifically for Windows 95,
OEM Service Release 2, and you want the header files to provide compile time access to these APIs,
it is necessary to define _WIN32_WINNT as 0x0400.
Notice that an application that uses these technologies will not run correctly on the retail release of Windows 95.
The vast majority of application programs that are expected to run on Windows 95 should be built without defining _WIN32_WINNT.


0

Featured Post

Courses: Start Training Online With Pros, Today

Brush up on the basics or master the advanced techniques required to earn essential industry certifications, with Courses. Enroll in a course and start learning today. Training topics range from Android App Dev to the Xen Virtualization Platform.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Connecting to MS SQL db from Win32 application written in C 3 85
What does std::atomic give me? 7 123
Lambda for random numbers problem 7 112
VS2015 Redefinition errors 4 47
In days of old, returning something by value from a function in C++ was necessarily avoided because it would, invariably, involve one or even two copies of the object being created and potentially costly calls to a copy-constructor and destructor. A…
Often, when implementing a feature, you won't know how certain events should be handled at the point where they occur and you'd rather defer to the user of your function or class. For example, a XML parser will extract a tag from the source code, wh…
The goal of the video will be to teach the user the difference and consequence of passing data by value vs passing data by reference in C++. An example of passing data by value as well as an example of passing data by reference will be be given. Bot…
The viewer will learn how to use the return statement in functions in C++. The video will also teach the user how to pass data to a function and have the function return data back for further processing.

813 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now