|
Hi all
How to validate the special characters like %,&,which should not be allowed to enter in the edit control in dialog based application.
I need to validate many special characters at a time.how can i validate.
|
|
|
|
|
Either write a filtered edit control (i.e. a control that does not accept certain characters) or filter the string as soon as the user hits "ok" and show him an error, if you find any characters in that field.
With std::strings you could use the .find-family of operations. You could, optionally, .remove any characters that you find unsuitable and then write the result back to the editbox, with a message-box for the user showing what he did wrong.
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
I suggest either use a masked edit control, or handle the ON_ENCHANGE notification. If any 'invalid' characters are found in the edit control, disable the OK button.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I am using Allan Nielsen's SuperGrid control in a project.
Setting of an option will cause the control to go inactive, but the control does not deactive in the 'standard way' when using EnableWindow(FALSE). The background of the control grey's out like normal but the check boxes and text does not. What I would like to happen when the item is deactivated is the selected item to become deselected and the item to be properly greyed out - not just blanket covered by a grey box as that looks unprofessional.
I have tinkered around with the code and looked at the DrawItem & ODS_INACTIVE but nothing i have done makes any difference. I need some frame of reference but no examples I can find on ownder drawn controls actually go into making them respond to EnableWindow command.
Thanks, G.
|
|
|
|
|
I would like to design an application in C++ that uses a gamepad to control a digital camera. The gamepad will have a USB connection.
Does anyone know where I can find information about how to communicate between the gamepad and the C++ application (How does the program know when a button is pressed for example)?
Thanks,
Kristian
|
|
|
|
|
The API used to read from joysticks and similar is called DirectInput, and googling around might get you some useful leads. Try here or here.
|
|
|
|
|
xkrja wrote: Does anyone know where I can find information about how to communicate between the gamepad and the C++ application
Yes, in the documentation supplied with your gamepad. You should have received a driver with it and some documentation explaining the commands that can be used.
A USB doesn't work like a COM port: you need to open the driver (with CreateFile) and then you can communicate with it by using DeviceIOControl[^] function.
|
|
|
|
|
Hi,
Im using dialog bar. Which has Only one CStatic ctrl.
Now i want to update the text(with current time) in the static ctrl on every second;
How can I achieve this.
Regards,
GAN
|
|
|
|
|
1. Create timer in the beginning of the application:
timer = SetTimer(1, 1000, NULL);
2. Add event ON_WM_TIMER()
void CMainFrame::OnTimer(UINT nIDEvent)
{
if (nIDEvent == 1)
{
// IDC_STAT is an ID of static controll
CStatic* cap = (CStatic*)m_wndDlgBar.GetDlgItem(IDC_STAT);
if (cap)
{
CTime t = CTime::GetCurrentTime();
cap->SetWindowText(t.Format("%d/%m/%y %H:%M:%S"));
}
}
CFrameWnd::OnTimer(nIDEvent);
}
3. At the end of the application don't forget to destroy the timer:
KillTimer(timer);
Nina
|
|
|
|
|
Hi nina
I wud like to make a suggestion (Objcet oriented way i think). it will be better if you write a function inside dialog bar like UpdateHelp(CString &str); and call it from MainFrame.
If u can Dream... U can do it
|
|
|
|
|
I am using this code:
FILE * pFile;<br />
char filename [100];<br />
<br />
pFile = fopen ("\\Settings\\temp.txt" , "rt");<br />
if (pFile == NULL) perror ("Error opening file");<br />
else <br />
{<br />
fgets (filename , 100 , pFile);<br />
fclose (pFile);<br />
}
to get a filename that another part of my program has written. However whatever I put in the text file my program reads 100 Í characters. Now when I open up the text file myself it shows exactly what I want, i.e. not that This is driving me slightly crazy so any help would be great.
P.S. If anyone wants the text file I am quite willing to e-mail it to you.
-- modified at 10:15 Wednesday 23rd August, 2006
|
|
|
|
|
You said another part of your program is writing the file?
Here are a few things to try:
- Initialize your string: char filename[100] = {0};
- Set the file cursor to the beginning explicitly: fseekg(pFile, 0, SEEK_SET);
- Make sure that the file is not currently open by the section of code that is suppose to be writing to it. You may be running into a race condition if you have 2 threads (for example) where thread 1 is writing to the file, but thread 2 is already trying to read from it before the write is complete.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Right, I have made sure that the other program isn't writing to the file. Initializing the char just results in the program returning a blank string. Using fseek doesn't seem to make any difference. Do you think it could be a problem with the format of the file?
|
|
|
|
|
stevelam wrote: Initializing the char just results in the program returning a blank string
That means that fgets isn't reading in anything for some reason. Check its return value to see if it is getting an error.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Ever tried with:
pFile = fopen ("\\Settings\\temp.txt" , "r");
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
|
|
|
|
|
|
How do you it returns only a bunch of Ì ? Is this in the debugger ?
Because the snippet you've provided is almost the example of the use of the fgets function in the MSDN, and it should work properly.
Have you tested it with another temp file ?
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
|
|
|
|
|
Right OK, I've found it, in the part of my program that wrote first there were some errors that corrupted the file. All is now working again, thanks for all of your help.
|
|
|
|
|
stevelam wrote: fgets (filename , 100 , pFile);
chage that to
if( fgets (filename , 100 , pFile) == NULL )
{
//ERROR
}
this prevent your prog from crashing.
there is nothing wrong with that part of your code the file could have been created in binary mode.
the buffer in this case filename could be currupted after the read op.
G_S
|
|
|
|
|
what don't you do that in a C++ way ?
STL is full of good things you know
|
|
|
|
|
hi,
Can anoboby tell me What are the differences in the debug mode & Release mode in details. what book i should refer to get good grip on this
|
|
|
|
|
debug mode should be used only for developement and debugging.
release mode is what you must use to deliver your apps.
to understand what happens, generate your application in both modes and compare the exe size... yes, the debug version is much bigger !!! that's because the compiler adds inside it some debug informations, lets the comments, don't perform optimizations, etc...
|
|
|
|
|
1. there's no debugging info in a release build - no good way to link the EXE back to the source
2. release builds are usually optimized, debug builds are not
3. some functions will work differently in release vs. debug (ex. new/malloc are quite different because the debug versions are designed to help catch memory leaks - the release versions are not)
4. things like ASSERT(x) behave differently because they rely on certain preprocessor flags (ex. _DEBUG) to control what they do
5. some data types may be initialized to 0 in debug build. they won't be, in release builds
etc..
-- modified at 10:03 Wednesday 23rd August, 2006
|
|
|
|
|
|
you can setup each of them to behave the way they want. even setup debug to work like release and release to work like debug.
we use only one mode for both and call it release_Debug. It has some debug info that is sufficient to get an idea of the problem. It helps as we have had problems in the past where our exe behaves differently in debug and release modes.
|
|
|
|