As Ryan says, the standard PC hardware supports a maximum of 115200 bit per second, as well as half that (57600), one quarter (28800), 14400, 9600, 4800, etc. Thus 141250 is not available with standard hardware. I made an interface a few years ago which used two Intersil 6502 UARTS, with different crystal oscillators for each and a little bit of glue logic components - receiving on one UART triggered transmission on the other, so this converted between different baud rates. No buffering or anything, so you had to "go slow". Try posting on the hardware forum - maybe some of the USB-to-serial adapters allow strange rates like you need.

Yes, they are defined in LIMITS.H Serge

I would argue that setting the pointer variable back to NULL after deleting the object is critical and highly recommended. If you do not, you are leaving a dangling reference to something that no longer exists. Once the memory is deallocated, by delete, the memory can be used for something else by another part of the program. If someone else is checking the pointer value against NULL, then the reset of the ptr to NULL will prevent a crash. My philosophy is that if the pointer doesn't point to anything then it should be null. NEVER EVER leave a pointer set to an address that is no longer pointing to a valid object. That is just asking for trouble in my mind. Of course deleting an object in the middle of program execution is tricky to begin with. There has to be an understanding between the piece of software responsible for deleting the object and the piece(s) of software using the pointer. Setting the pointer back to NULL is a simple way of establishing that understanding. If the pointer is NULL, don't use it! //perhaps this is done in the constructor of a class and the pointer //mlpszFilePath is a member variable of some class. LPTSTR mlpszFilePath = NULL; //Now in some member function you do this: //Only build the string if it has not already been built if(lpszFilePath == NULL) { mlpszFilePath = new _TCHAR chFilePath[_MAX_PATH]; } //later you'd do this: //Only delete the array if it has been previously allocated; perhaps in a class destructor. if (mlpszFilePath != NULL) { delete[] mlpszFilePath ; mlpszFilePath = NULL; } //Perhaps you have a function to get the pointer const LPCTSTR GetPointer() const { return mlpszFilePath; } Perhaps a string is a bad example but you might have this kind of code where you have to new and delete some object that is placed in the global scope via a pointer variable that many components of an application need access to. Notice that the setup allows the same object to be reused over and over. This type of pattern is very common and sort of applies to your other question about performance surrounding new and delete. Yes, new and delete require system resources like any function call or calculation; but the operating system is designed to perform memory management for you so that you don't have to worry about it. If you are only rarely using new and delete to allocate a string it's not a big deal. If you are doing it thousands of times in a second, then that could be a problem. If the function using the string o

Like: GetDlgItem(IDC_LIST1)->ModifyStyle(0, WS_THICKFRAME, SWP_DRAWFRAME); If you say wanted to turn on WS_THICKFRAME at runtime. Or GetDlgItem(IDC_LIST1)->ModifyStyle(WS_THICKFRAME, 0, SWP_DRAWFRAME); To remove

You will need the DDK to get the docs, headers, and libs. The relevant functions are CM_Locate_DevNode(), CM_Query_And_Remove_SubTree(), and CM_Request_Device_Eject() --Mike-- Personal stuff:: Ericahist | Homepage Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ ---- Pinky, are you pondering what I'm pondering? I think so Brain, but how will we fit the hamster inside the accordion?

Yes, the size was a result of adding the excpetion blocks, maybe i use too extensive, every functions i use the exception to protect the codes in case there is any errors resulting in unforseen cases. initially, it helps me in debugging, after solving the bugs, so far, the exception was never resulted but frankly speaking, it is hard to predict what user can do to it since there is user entry portion. I checked MS website, it was indicated that the __try __ except is WIN32 exception handling. and they also indicated not all cases can be captured by the __try block.

Try the WM_KILLFOCUS Message will help to your problem All the best

If the ThreadProc is declared as follows: DWORD WINAPI ThreadProc( LPVOID lpParameter // thread data ); Why don't you just return 0; from your thread function instead of calling ExitThread at the every end of it anyway? Then your variables can go out of scope and destroy themselves automatically. Anything monitoring the 'exit code' of the thread will still see the 0. FYI (From MSDN): A thread that uses functions from the C run-time libraries should use the _beginthread and _endthread C run-time functions for thread management rather than CreateThread and ExitThread. Failure to do so results in small memory leaks when ExitThread is called.

IceBerG71 wrote: Anyone know how to determine if a file is opened as Read or Write through any of the APIs... Do you really need that level of granularity? It's usually sufficient to know whether the file is opened exclusively or not. "The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)

Try GetFileAttributesEx() Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke

WriteFile is a low level call. It simply writes data to the disk. (The OS actually does some minor caching, but it's not significant.) fwrite() writes data to an intermediate buffer (4k by default, I believe) when the buffer fills, the buffer is written to disk using a single call to WriteFile. The same thing goes for reading data, only in reverse. So, if you are reading/writing lots of smaller strings, you will get better performance with fread/fwrite unless you implement your own caching algorithm. Note that you can get the original file handle by calling _fileno() with the proper FILE* and use that to call other functions directly (though doing any call that affects the file pointer (i.e. ReadFile, SetFilePointer, etc.) withough calling fflush first, will totally mess up the stream buffers. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke

IceBerG71 wrote: what is RTTI actually? Run Time Type Information. It is the standard conformant way of determining a type at runtime. The same is done in MFC with things like IsKindOf(), but with this approach all objects need to have the same base class (CObject). Who is 'General Failure'? And why is he reading my harddisk?!?

Another factor to consider is the limited amount of stack available; by default, you have 64KB of stack, which has to encompass all of your thread's execution. If you run out of stack, Windows CE will raise a Stack Overflow exception. You shouldn't try to catch this - it indicates a serious problem. If uncaught, the thread will be terminated. You should really only use the stack for short-lived items and in leaf functions (functions that call no other functions). Using the stack for anything that will have a long lifetime (e.g. your main frame window) isn't a good idea.

Do this: 1 - Create the font you want to use 2 - Retrieve the control's HWND using GetDlgItem 3 - Use SetFont (MFC) or WM_SETFONT to set the font 4 - Destroy the font when the dialog closes Regards, João Paulo

Sorry, i did not furish with more details. the target device is on an embedded device with customize Window CE and using embedded Visual C++ 3.0. So i dun think Access is a good choice since memory consideration is critical. i have been using Access on my PC application and it had given me quite a few problems.