|
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)
{
.........
}
|
|
|
|
|
Do you think the compile error could be because the compiler doesn't recognize the syntax? Here is the compiler output:
"usrfunct.c", line 91: error #2020: identifier "nparm" is undefined
long TAPEINFO(nparm, parmptr, parmdec)
^
"usrfunct.c", line 91: error #2020: identifier "parmptr" is undefined
long TAPEINFO(nparm, parmptr, parmdec)
^
"usrfunct.c", line 91: error #2020: identifier "parmdec" is undefined
long TAPEINFO(nparm, parmptr, parmdec)
^
"usrfunct.c", line 92: error #2130: expected a "{"
WORD nparm;
I've actually been emailed the source and just asked to see if I can figure out why it won't compile. I think it is an HP UNIX box. By looking at the make log it seems like the compiler is called aCC. Once again never seen this but have never worked with C on HP UNIX before.
Thanks for your help.
|
|
|
|
|
What compiler and version are you using?
CC is usually an environment variable pointing to whatever C-compiler you want to use. Typically, you will see the makefile (or configure script) have something along the lines of:
CC=gcc
...
$(CC) $(CFLAGS) usrfunct.c
Depending on what compiler you are using, you may have to set a flag to allow it to read old-style syntax (K&R C).
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
