|
My problem -
I wrote an application that reads com port in a loop and stores received data in log file.
Everything was O.K. , but then i needed to add *.ini file to my app. I`ve constructed a small inifile class to get port settings, etc. from *.ini. Everything works just fine, but, one thing. For example - to define BaudRate i used my inifile class to return int value fo parameter e.g 9600 not CBR_9600.
As i came to StopBits section I realized that ONESTOPBIT is defined as 0 which, which means - I have to store StopBits as its int value - 0. The thing that bothers me is that it`s hard for user to understand - why the hell section StopBits has to be 0, not ONESTOPBIT or 1. Is there any way I could store this value in my config file as string "ONESTOPBIT" and then pass it to DCB as its defined value, without using switch or any other unneeded stuf in my inifile class. Hope somebody will be able to understand what I wrote here..... Please help - I`m stuck on this for whole day already...
|
|
|
|
|
what's wrong with reading in a string, comparing it to a value (or looking it up in a table of
values), and passing on the appropriate integer?
TCHAR szValue[128];
(...read string into szValue from ini/configuration file...)
DWORD dwStopBits;
if (0 == _tcscmp(szValue, _T("ONESTOPBIT"))
dwStopBits = 0;
else
dwStopBits = 1;
>>...without using switch or any other unneeded stuf...
If it makes it easier for the user, is it really unneeded? Sometimes a little code is required
IMO 
Mark
|
|
|
|
|
As far as the setting is for StopBits - no problem, but think about what happens, when you want to set baudrate(there are more options available) or, for example pass some GENERIC_READ to CreateFile() e.g. Could this be that there is no way to store DWORD defined variable in *.ini file, and then pass it back to app??
|
|
|
|
|
First
I agree with Zac that XML is a better way to go.
If you must use an ini file there's no problem converting text to a DWORD...
Take a look at atol() and similar functions which convert text to numeric values.
As always, you'll want to check the validity of anything entered by a user
Mark
|
|
|
|
|
Instead of using an INI file, you might try using an XML file. It will be easier to group settings (so if you ever decide to store multiple settings in the same file -- say, for multiple com ports), and it is easier to incorporate type checking.
The value of ONESTOPBIT is 0 because there are 3 values for stop bits (1, 1.5, and 2). Since it isn't good to use a float/double for such, an integer is used (basically as an enum). If you want to allow users to edit the configuration files manually, just use strings and assume default values if the strings are invalid.
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
|
|
|
|
|
Thanx for reply - ill stick to using switch() or that kind of stuff in this case, but the method for storing ONESTOPBIT e.g as string and then read back its defined DWORD value still bothers me - I want to figure it out...
P.S.
Yes - I know about xml files, but this isn`t the case I would need it.
|
|
|
|
|
Makakuin wrote: Thanx for reply - ill stick to using switch() or that kind of stuff in this case, but the method for storing ONESTOPBIT e.g as string and then read back its defined DWORD value still bothers me - I want to figure it out
Are you saying you want to store it like this:
; Valid values are ONESTOPBIT, ONE_5STOPBIT, TWOSTOPBIT
StopBits=ONESTOPBIT
or like this:
; Value values are 1, 1.5, 2
StopBits=1
In the first case, just use string comparisons. In the second, you have a couple options as well: Read them in as floats and use conditionals to set them to the proper setting (a bit risky since precision can be an issue), or force the values to be multiples of 10x so the file would look like this instead:
; Value values are 10, 15, 20
StopBits=10
Then simply use a switch statement to convert those integers to the proper defined values for stop bits.
Your best bet for making it easily readable is still to use XML and create a schema to validate it against so that you can let the parser determine if you have valid values before you even look at the data.
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
|
|
|
|
|
What I mean is:
For now I use:
//////////////////////////////
DCB dcb;
dcb.BaudRate = inifile.getInt("Baudrate"); //Accepts int
dcb.StopBits = inifile.getInt("StopBits");//Accepts int
//////////////////////////////
and so on...
inifile is my created class where getInt(char* paramname) is returning value of type 'int', which is acceptable to DCB class. As you know originaly it would be done like this:
/////////////////////////////
dcb.BaudRate = CBR_9600; //Accepts DWORD
dcb.StopBits = ONESTOPBIT; //Accepts DWORD
/////////////////////////////
where CBR_9600 and ONESTOPBIT are defined by c++ like 9600 and 0.
What I want to do is store those settings in config file (doesn`t matter ini or xml) as strings CBR_9600 and ONESTOPBIT and then read them.
This won`t work:
//////////////////////////////
dcb.BaudRate = inifile.getTxtVal("BaudRate");
//////////////////////////////
because getTxtVal() returns char[] (wich is not acceptable for DCB) variable containing CBR_9600.
May be it is now easyer to understand what i was trying to say.... 
But maybe I`m a lOl.
-- modified at 15:30 Thursday 12th October, 2006
|
|
|
|
|
Makakuin wrote: strings CBR_9600 and ONESTOPBIT
You can store them as strings, but you will have to do a string comparison in your code to convert them. ONESTOPBIT, CBR_9600, etc are usually either #define's or enums (can't remember off the top of my head, but it doesn't matter). If you get a string "ONESTOPBIT" in, you can't convert that to ONESTOPBIT (the constant) by just casting it; you have to tell it what you want it to be:
string sBaud = inifile.getTxtVal("BaudRate");
unsigned long baud = CBR_38400;
if (sBaud == "CBR_9600")
{
baud = CBR_9600;
}
else if (sBaud == 14400)
{
baud = CBR_14400;
}
...
dcb.BaudRate = baud;
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
|
|
|
|
|
Thanx that was exactly what I wanted to know .
It`s a pity that there`s no way to use the returned string directly..
O.K. ill start to write the missing piece of code for my inifile class..
Thanks again!
Raivo Jirgensons
|
|
|
|
|
Makakuin wrote: It`s a pity that there`s no way to use the returned string directly.
You have to keep in mind that enums and defines are NOT strings. enum's are basically constant integers and defines are preprocessor directives that get changed out before compiling.
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
|
|
|
|
|
sorry i misstyped getTxtVal() returns char[] not char*
|
|
|
|
|
Makakuin wrote: where CBR_9600 and ONESTOPBIT are defined by c++ like 9600 and 0.
What I want to do is store those settings in config file (doesn`t matter ini or xml) as strings CBR_9600 and ONESTOPBIT and then read them.
So why can't you? Use sprintf(), or equivalent, to format the string and then write that string to the .ini file. Are you looking for atoi(), perhaps?
Otherwise, I'm just not following what you are after. Perhaps you could show what you want the .ini file to look like.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I was doing a lot of cut and paste on several dialogs, but then I look at the resource.h file, some defines have the same value.
Are they any programs to check this file and correct the problems.
See sample below:-
#define IDC_POWER_LABEL 1742<br />
#define IDC_MAIN_RX_SQUELCH_LABEL 1743<br />
#define IDC_MODULATION_LABEL 1744<br />
#define IDC_COMBO1 1745<br />
#define IDC_COMBO_MODULATION 1746<br />
#define IDC_START_IBIT_LABEL 1746<br />
#define IDC_GUARD_RX_LABEL 1747<br />
#define IDC_TEST_TYPE_LABEL 1747<br />
#define IDC_GUARD_RX_BUTTON 1748<br />
#define IDC_IBIT_STATUS 1748<br />
#define IDC_GUARD_FREQ_LABEL 1749<br />
#define IDC_TEST_TYPE_STATUS 1749<br />
#define IDC_COMBO_GUARD_FREQ 1750<br />
#define IDC_WARNINGS_LABEL 1750<br />
#define IDC_MARITINE_SHIP_SHORE_LABEL 1751<br />
#define IDC_WARNINGS_STATUS 1751<br />
#define IDC_SHIP_SHORE_BUTTON 1752<br />
#define IDC_ERRORS_EXIST_LABEL 1752<br />
#define IDC_MARITIME_INT_USA_LABEL 1753<br />
#define IDC_ERRORS_EXIST_STATUS 1753<br />
#define IDC_INT_USA_BUTTON 1754<br />
#define IDC_SRUS_ERRORS_LABEL 1754
Help!
|
|
|
|
|
I had one problem with same IDs like your code so my suggestion use of different values.
|
|
|
|
|
WhiteSky wrote: ...my suggestion use of different values.
No kidding! He already wants unique numbers. His question was about a program to do that for him. 
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I think ResOrg ( found here on CP ) can do that.
|
|
|
|
|
Maximilien wrote: I think ResOrg...
Yes, I'm already aware of it.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Has this program been updated for VS 2005.
I had problems with it om VS 2003, does most of the things wright but gets IDD for the Aboutbox and Menu wrong.
Andy.
grahamfff
|
|
|
|
|
Grahamfff wrote: Has this program been updated for VS 2005.
Wouldn't know. I don't use it.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Andy202 wrote: some defines have the same value.
it doesn't matter if the relative controls are on different dialogs...
|
|
|
|
|
That's correct, you may have exactly the same control IDs in different dialog boxes.
The simplest example is: IDOK, IDCANCEL.
Regards
|
|
|
|
|
Unless you want to map the control ID to a help file context using MakeHm or something similar, in which case you want ALL controls to have unique ID within the application - at least all of them that will have context-sensitive help.
Maybe that is why he wants them all to be different.
Any sufficiently gross incompetence is nearly indistinguishable from malice.
|
|
|
|
|
Hello Everyone.
I have the following C code snippet:
long TAPEINFO(nparm, parmptr, parmdec)
WORD nparm;
BYTE **parmptr;
FINFO *parmdec;
{
....Code in the function goes here....
}
I'm not an expert by any means in C but I have done a litte C development on Linux and have never seen code like this before. The variables that are defined directly below the function header seem wierd.
The problem is a compile error stating "nparm is undefined" and pointing at nparm in the function header line.
Is the definition after the function header supossed to define nparm?
If someone could provide any feedback I'd appreciate it.
Thanks.
|
|
|
|
|
It is an old Kernighan and Ritchie (K & R) style function equivalent to
long TAPEINFO(WORD nparm, BYTE **parmptr, FINFO *parmdec)
{
.........
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
