The solution which you have given is working fine for me in windows machine But now I need to implement the same thing (utf-8 to ascii conversion) in a POS terminal which neither has 'locale.h' nor _wcstombs_s_l in the stdlib.
The POS terminal has linux kernal.My quries are :
1)Instead of using the function _wcstombs_s_l and create_locale can I replace it with the function definition itself.
2)If I can then please if possible provide me the link where I can find the proper definition of these two functions.
3)If i can not then is there any other way to implement utf8 to ascii conversion.
You should be aware that all solutions involving wcstombs and related depend on the locale and the typical encoding might not be what you call 'ascii'.
Actually, what is called ASCII does not contain any Arabic characters whatsoever. Probably, you are referring to a specific codepage that uses ASCII + some Arabic characters?
In that case, it's probably a good idea to set the proper locale before conversion (see Richard MacCutchans post for info), so you get the correct codepage and not, as you probably get with the code given so far, UTF-8 encoding, which means that the text file will contain multiple bytes per character.
Locales and encoding are a quite complicated issue, so you should be careful and precise when using them. Also, by C++ definition the locale employ system-dependent strings for locale, so if should cater to the platform you are coding for.
David's pointing you to the spec is an excellent answer.
A few things I will add to the mix:
* You will need multiple commands ( SECURITY ERASE PREPARE, SECURITY ERASE UNIT, and possibly other SECURITY commands ) from the spec in order to accomplish a secure erase.
* Sending (single-sector) ATA passthru commands from uesr mode applications is possible on Windows (XP SP2 and newer, IIRC), assuming you have Admin privileges on the system. You will need do some Googling on IOCTL_ATA_PASSTHRU_DIRECT in order to find relevant information.
* That being said, you will still be at the mercy of the system BIOS and possibly the O/S. Once a SECURITY FREEZE LOCK is sent to the drive, it is *generally* difficult or impossible to send SECURITY ERASE to the drive. Some motherboard BIOSs send the SECURITY FREEZE LOCK prior to start of boot just to ensure a drive is not accidentally or maliciously erased.
All of this is from my memory, which is several years old at this point.
Have a look at this article HOWTO track a user's idle time[^]; it seems to have a good implementation on how to detect the idle time.
When the idle time (five minutes) has been reached you could show a modal dialog that requires the user to specify his/her user name and password.
I have an application that can also run as a service via srvany. It performs a monitoring task and uses the PlaySound method defined in mmsystem.h to play a .wav notification on certain events. It runs fine under XP as an app or as a service.
Under Win7, the app runs fine. But when running as a service under Win7, I get no sound. The "allow service to interact with desktop" option is available but ignored under Win7 as part of Session 0 isolation. I expect this is somehow related.
I'm looking for verification or alternate approaches.
You are most likely right in your conclusion. I think the session 0 isolation prevents such interactions.
A possible work-around is to have your Service start or interact with a non-service component that runs in the user session.
In a Debug build the compiler performs additional tasks, for instance it zeroes variables you haven't initialized (e.g. WinAPI structs) (in Release build the unitialized data contains garbage).
Have a look at the following CodeProject article: "Surviving the Release Version"[^].
Check your CMyApp::OnFileOpen() code and the functions that are called from there. Comment all lines in that function except the base class CWinApp::OnFileOpen() call and uncomment step by step until the violation occurs. Then you should know which part of your code is responsible.
If you did not call CWinApp::OnFileOpen(), no document is created. So the reason for the crash is probably somewhere in your document creation. Did you call OnFileNew() or use ProcessShellCommands() to create a document?
No, I didn't call CWinApp::OnFileOpen, but I call OpenDocumentFile(...), something like that:
if(IDOK == dlg.DoModal())
POSITION pos = dlg.GetStartPosition();
// the document is loaded, I can see the bitmap in child frame ...
AfxMessageBox("By here, everything it's OK.");
after all, I think that the problem it's in another place ... I really don't know ...
And this is weird, because if I open the same file from MRU, everything is OK ...
modified 5-Apr-13 5:54am.
Last Visit: 31-Dec-99 18:00 Last Update: 28-Sep-23 20:15