In the documentation for TimeProc, the remarks section says:
Remarks
Applications should not call any system-defined functions from inside a
callback function, except for PostMessage, timeGetSystemTime, timeGetTime,
timeSetEvent, timeKillEvent, midiOutShortMsg, midiOutLongMsg, and
OutputDebugString.

In the SDK sample code for the timer callback routine there is reference to
(presumably) a user routine to handle the timer task (TimerRoutine(npSeq);
in the code sample):

      Platform SDK: Windows Multimedia

Writing a Timer Callback Function
The following callback function, OneShotTimer, invalidates the identifier
for the single timer event and calls a timer routine to handle the
application-specific tasks. For more information, see TimeProc.

void CALLBACK OneShotTimer(UINT wTimerID, UINT msg,
    DWORD dwUser, DWORD dw1, DWORD dw2)
{
    NPSEQ npSeq;             // pointer to sequencer data
    npSeq = (NPSEQ)dwUser;
    npSeq->wTimerID = 0;     // invalidate timer ID (no longer in use)
    TimerRoutine(npSeq);     // handle tasks

Does the remark for the callback function apply to routines called by that
fuction?  In the system I am working, I want to send a message out via the
serial port (using the WriteFile method targeted at the serial port -- see
below) at a fixed rate.  For timing reasons, the multimedia timers provide
the best resolution and accuracy.  To avoid delays from posting messages, I
would like to do the WriteFile as part of the timer experiation processing.
Can I put it in a routine called by the callback funtion?

Thanks!

Don

Serial Port set-up:

  sprintf(commport, CommPort);
  PortHandle = CreateFile(commport, GENERIC_WRITE | GENERIC_READ,
      0, NULL, OPEN_EXISTING, 0, NULL);

  if( SetupComm( PortHandle, 2048, 2048) == 0 )
  {
   printf("\n\nBuffer Sizes NOT Updated\n  ");
  }

  /* Settings for commport */
  GetCommState(PortHandle, &CommSettings);
  CommSettings.DCBlength = sizeof(DCB);
  CommSettings.BaudRate = CBR_38400;
  CommSettings.fBinary = TRUE;
  CommSettings.fParity = TRUE;
  CommSettings.fOutxCtsFlow = FALSE;
  CommSettings.fOutxDsrFlow = FALSE;
  CommSettings.fDtrControl = DTR_CONTROL_DISABLE;
  CommSettings.fDsrSensitivity = FALSE;
  CommSettings.fTXContinueOnXoff = FALSE;
  CommSettings.fOutX = FALSE;
  CommSettings.fInX = FALSE;
  CommSettings.fErrorChar = FALSE;
  CommSettings.fNull = FALSE;
  CommSettings.fRtsControl = RTS_CONTROL_DISABLE;
  CommSettings.fAbortOnError = FALSE;
  CommSettings.ByteSize = 8;
  CommSettings.Parity = EVENPARITY;
  CommSettings.StopBits = ONESTOPBIT;
  SetCommState(PortHandle, &CommSettings);

  /* Settings timeout values */
  GetCommTimeouts(PortHandle,&timeout);
  timeout.ReadIntervalTimeout = 500;
  timeout.ReadTotalTimeoutMultiplier = 500;
  timeout.ReadTotalTimeoutConstant = 500;
  timeout.WriteTotalTimeoutMultiplier = 1000;
  timeout.WriteTotalTimeoutConstant = 1000;
  SetCommTimeouts(PortHandle, &timeout);

void CSerialInterface::SIO_ByteArray( unsigned int* OutputArray, int
OutputArrayLength )
{
 unsigned long    BytesWritten;

 if( SIO_Options & SIO_WriteToComm )
 {
     /** --------------------------------------------------  **/
     WriteFile(PortHandle,
         OutputArray,
         OutputArrayLength,
         &BytesWritten,
         NULL);
    }

You can't get around the restriction by simply calling another
function.  The same rules still apply in called functions.  Sorry :(

--
Scott McPhillips [VC++ MVP]

You might want to post again in the multimedia group. In the bad old days of
16 bit Windows, and perhaps on 95, the callback fired from inside an
interrupt service routine. That caveat applied because a developer can do
serious damage inside an ISR if he is not careful.

I might be wrong but I have a hard time believing will let you get inside an
ISR so easily. Of course there could be other reasons why the caveat applies
but it may be the case that you have more freedom on NT. You might want to
check in the mm forum.

You may also want to look at CreateWaitableTimer(). You can do anything you
like inside its callback. The only issue is that the callback doesn't fire
unless the calling thread is in an alertable wait state.

Regards,
Will

Is there an accepted approach for dealing with situations such as this
(restrictions as to what system functions can be called from a callback
function)?  Is using the PostMessage about the best approach?

Thanks!

Don