But as you can see this is much more code and it is insecure without checking for buffer overflows (which adds more code).
If you don't need the data to be in text format (e.g. only loaded by your application), it might be better to write the data to a binary file. That solves also the problem of inaccuracies when converting floating point values to text and back again later.
FILE *f = fopen(fileName, "wb");
fwrite(&newForce.x, sizeof(newForce.x), 1, f);
// Write other items here
Reading is then done in a similar way:
FILE *f = fopen(fileName, "rb");
fread(&newForce.x, sizeof(newForce.x), 1, f);
// Read other items here
Using the width specifier, all numbers will have the same width padded with blanks. For proper alignment of the decimal point you should also use the precision specifier and the flag specifier (use a space or minus). The final values to be used depend on the range of your values and the required precision. Assuming a range up to (but excluding) 100 and a precision of 2 fractional digits:
Precision = 2
Width = 1 (sign) + 2 (digits) + 1 (decimal point) + 2 (digits) = 6
The data i'm getting is of very large sample. I use a inbuilt thread class calls at very high frequency. Basically I want to reduce the sampling rate so that I'll get significant data with less samples..Do you have any idea how to create periodic thread with a fixed frequency?
Basically two functions one is for updating graphics and other for haptics rendering. Haptic rendering sampling rate is quite large compared to graphics. In the library I'm using there is a thread class basically gives priority to haptic and graphics rendering. But I'm not able to see any section in the code where they access system timing and setting sampling rate etc.
I'm thinking about assigning some condition inside data will be written into the file at a rate of 100 samples per second. There is an inbuilt precision clock with the library, so if I've I can get cpu time with precision clock , how can formulate a condition to write data at a rate 100Hz??
As far as I understood you have a haptic device which is some kind of hardware which generates data at a frequency defined by the hardware. If the library does not provide functions to set the sample rate, it is probably fixed. The thread is then activated when new data are available.
But again, without knowing the hardware and the library (which acesses the hardware specific driver), it is rather impossible to answer.
Do you want to write the data to a file with 100 Hz. This is probably too fast (especially when the file must be opened for each write). It again depends on your requirements (who is reading the file). If the data should be read by another process, you may use some kind of IPC (Inter Process Communication).
Windows has no high resolution timers. While it is possible to measure times with high resolution (QueryPerformanceCounter), the system timers have a resolution of about 10 ms by default and can be tweaked down to 1 ms.
Just call Sleep() with a time out value of 1000 / frequency[Hz].
A better implememntation would use WaitForSingleObject() with the same time out value and a handle to a terminate thread event so that you can terminate the thread:
UINT worker_thread_func(LPVOID pParam)
// pParam is usually a pointer to a C++ class to which this thread belongs// that is passed when creating the thread.// Cast the pointer to get access to member vars.
MyClass *pThis = (MyClass *)pParam;
HANDLE hKillEvent = pThis->m_hKillEvent;
if (WAIT_OBJECT_0 == WaitForSingleObject(hKillEvent, TIME_OUT_VAL))
// Perform periodic task here
I still didn't get idea of using WaitForSingleObject() as a timer. Basically WaitForSingleObject is a predefined function under windows.h? right?. Can you bit explain how exactly this can be embedded with a project?
It is a Windows API function that is used with threads. It will suspend the thread until the event specified by the passed handle occurs or the time out time has elapsed.
Using threads is an advanced topic. So you should read about it first. A starting point may be Using Worker Threads[^].
Your requirement was to execute specific tasks in fixed intervals. This can be done by Windows timers from within your main (GUI) thread. But this will block the main thread for the task execution time. With short intervals, this will lead to delayed user input (mouse and keyboard actions are not performed immediately). To avoid this, a worker thread can be used.
I very rarely ask programming-specific questions in public forums, but this one has me completely stumped.
I just can't seem to get the Windows Native API function, "Shell_NotifyIcon" to work, no matter what I try.
This is the Windows API function that enables an application to add its "Icon" to the Windows System Tray, aka: the "System Notification Area", and then enables it to pop up "notifications", etc..
At least, in theory..
No matter what I try however, this function always fails in my app.
And when I call the GetLastError() function to try to determine what was allegedly wrong with the call, sometimes I'll get a "timeout" error (whatever that means), sometimes I'll get an "invalid window handle" (but the handle's perfectly valid), and other times the call will actually succeed, but the very next call will fail with the same variable results..
I'm compiling in Windows 64-bit using Visual C++ Express, BTW..
I've tried calling both the ANSI and Unicode versions of this function and get the same results. I've tried specifying different "versions" to this function (it's a parameter), and I get the same results. I've tried compiling both with and without "enabling Visual Styles", but, you guessed it, same results..
And I've looked at all the sample code on the Internet that uses this function, including most of the code on this site, and without exception, none of the code I've looked at is doing anything more than my own code is doing..
Which is all, needless to say, exceedingly frustrating..
My app also changes its own execution priority, so I took that out to see if it would make a difference - it didn't..
I also came across an excellent article on Shell_NotifyIcon on the Internet:
The same Dialog Box procedure also calls two other Tray-related functions, Min2SysTray(), which attempts to add the Tray Icon, display a notification, then hide the Dialog Box, and ProcMsgFromTray(), which processes messages from the Tray.
All three are invoked from the same Dialog Box procedure in the following way:
static INT_PTR CALLBACK MainDlg( HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam )
switch ( uMsg )
switch ( wParam )
case SC_CLOSE: // <== ..as for example..
QuitThisApp( hDlg );
return( true );
case IDM_About: // <== ..as for example..
MAKEINTRESOURCE( IDD_About ),
hDlg, AboutDlg, 0 );
return( true );
case SC_MINIMIZE: if ( Min2SysTray( hDlg ) ) return( true );
// << bunch of other cases >>case MSG_FROM_TRAY:
ProcMsgFromTray( hDlg, wParam, lParam );
return( true );
Init_NID( hDlg );
return( true );
case WM_DESTROY: PostQuitMessage( 0 );
return( false );
From code you posted it seems very improbable to me that it can work with memory dynamically allocated (new) for NOTIFYICONDAT. This memory is released when sub exits, while it is not reused may happen that it works, as soon it is reused and filled with data making nosense for IconNotify it will not work anymore.
The problem you mentioned is related only to services and program that starts before desktop (iexplorer) is started (that is the case of utilities wrote by the author of article you mentioned). In that case the solution is to wait for initialization to complete. You will find all info, if you need, here[^].
Making it static and changing the access to its members it works for me.
This is the amended code:
Apologies. I made a mistake in transcribing the original code.
Which actually has nothing to do with why this code still doesn't work - just to be clear.
In the original code, the NID->szTip, NID->szInfoTitle, and NID->szInfo structure members are not initialized by strcpy(). I changed it to a bunch of strcpy() calls to "simplify" the code (to make it easier to read)..
They are initialized in the original code by a function call whose return value sets an auto bool called, "Opning". When I substituted out that function call for those strcpy() calls (for simplicity), I also (erroneously) took out the "bool Opning =" part.
To make a long story short, the following is a far more correct "transcription" of the existing code:
However, as is readily apparent from the above code, it is incorrect to say that the "memory is released when sub exits". The memory is only released if the function fails to initialize the entire structure.
Thing is though, even if the function does fail (which BTW, I've never seen it do, and I've debugged this a lot), then the NID variable would get set to NULL, which would prevent the Shell_NotifyIcon() function from ever getting called (because the function that calls it checks the NID before it does anything else).
And to forestall the inevitable question, yes, I am sure that my "LoadString()" function is not overwriting any other structure members (with strings too big)..
Anyway, the structure always initializes fine, so I don't think that's the problem.
I am curious though, about what you meant when you said that it "works for me"? Are you compiling in 64-bit?
I see, I have misinterpreted the usage of new in your code.
What I mean is that I compiled a sample with a C (not C++) compiler and it works for me.
The only problem I found compiling the code in 64bits is that a manifest resource is required.
This is my full sample:
and voila! No need to create a manifest resource.. Assuming, of course, that you're using some reasonably recent version of Microsoft Visual Studio..
Of course, as you may have already surmised, I'm telling you this in the hope that you'll try compiling your code in 64-bit, and apprise me of the results that you get..
If my suspicions are correct, your code, like mine, won't work in 64-bit..
If I'm wrong about that, then that would be almost as good (actually better in the long term). Then I'll just take your code verbatim, and start adding in bits of my other stuff until it fails. In my experience, bugs are rooted out far more easily when you're adding to code that works, as opposed to attempting to subtract from code that doesn't..
But I kinda need to know that the 64-bit Shell_NotifyIcon() works for someone, *anyone*, before I go down that (very long) road.. Because at this point, I don't think it will..
Anyway, thanks again for your help. I see that you're still insisting on a static NID as opposed to a static NID pointer.. Well, six of one, half dozen the other - you know. The reason I made it a pointer (and yes, in my own code, it's still a pointer) is because the whole System Tray thing is an End-User option, so why allocate memory that might never be used? And because making it a pointer allows it to double as a kind of boolean - if it's not NULL, it means that all steps of the initialization succeeded, and if it is NULL, then don't use it at all.. Kind of an all-or-nothing approach..
And last and least, I think we both know that that silly "Opning" variable doesn't need to be in either your code or mine. To be sure, it still serves a purpose in my original code, but I left it in here (this forum) only out of respect for the narrative - it is completely superfluous..
Anyway, I'm being far too verbose - it's late; too much coffee.. Need to..
Last Visit: 18-Jul-19 2:54 Last Update: 18-Jul-19 2:54