|
To create your controls dynamically, you can use the member function Create in which you have to specify the ID of the control, the position of the control, ... So, you don't have to place them wiht the resource editor.
For the listbox, you can find (I think) a good tutorial on this website (search in the MFC section)
|
|
|
|
|
There are two ways of operating here :
1. As Cedric suggest, create the control you need dynamically, e.g. on the fly.
2. Create all controls in the resource editor, and hide/show them using the ::ShowWindow() API with SW_SHOW or SW_HIDE as parameter. This will look completely messy in the resource editor, but if you only have say two or three controls overlapping, it can still be handled.
The first solution is by far the best.
~RaGE();
|
|
|
|
|
|
Hi,
you could use child forms to show/hide depending on the selected item in the listbox.
Then you can still use the designer to create the window with only the needed controls.
codito ergo sum
|
|
|
|
|
I do this same thing with our job-scheduling product. On one page is a handful of radio buttons. Depending on which radio button is selected, other controls are shown/hidden for further input. Works great.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
so, in the resource editor you have many buttons, one top of other ??
- KK
|
|
|
|
|
That is correct. With highly volatile dialog boxes, that might be an issue, but these dialog boxes have not had any major changes in years.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
I am using it. Thanks. Still there is a problem
I have a group of three radio buttons. In that only first has "Group" checked in the properties.(as required, because only one of those should be selected)
problem is I can add variable only to that one and can hide only that one using ShowWindow(SW_HIDE)
Other radio buttons, ones without group property does not get hidden.
HOW TO DO THAT  ??
- KK
|
|
|
|
|
You need a CButton variable for each radio button. You can do this via ClassWizard, but it will require that you temporaily add the WS_GROUP style to each of the three radio buttons. Once you get a CButton variable for each radio button, go back and remove the WS_GROUP style from all but the first radio button control.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
ThatWorked. nice trick. Thanks so much !! 
- KK
|
|
|
|
|
Hi,
How could I get all the section names in an ini?
I know the below.
dwLen = GetPrivateProfileString( NULL, NULL, lpDefault, lpResult, nSize, lpFileName );
It will store all the section names to lpResult. But how can I estimate the nSize, when I am unknown about the section name count and size?
I have to find the nSize first, to allocate the memory for lpResult sothat I can get all the section names. What would be the solution?
Thank you.
- NS -
|
|
|
|
|
|
Nothing is there related to my context...
It is for simple read and write...
- NS -
|
|
|
|
|
|
Three remarks:
1. GetPrivateProfileString is usually used to handle one entry at a time, which entry you of course know the size of.
2. For entries which have no fixed size (strings), you can take a default size for your buffer (MAX_PATH ?) or you can associate another key of size integer which contains the size of the string.
3. Same for keys that contain various amount of subkeys (like most recent used lists, and so), you usually store a parallel key containing the amount of keys to read.
So, if the information has been written properly, there should be a key containing the size you are needing.
If not, you are probably trying to read too much at a time and need to read the keys recursively.
A dirty trick to achieve what you are trying to do, is to do a loop in which you check the returned value dwLen against the buffer size nSize. Increment nSize until it is different from dwLen, in this case you are sure that everything has been read properly. Something like (this is pseudocode):
while (sizeread >= nSize)
{
nSize+=1024
sizeread=ReadKey(nSize)
}
This snippet obviously does not work, but I think you can get the idea.
~RaGE();
|
|
|
|
|
I understood... but what i need is:
An ini file contains a lot of sections and keys.
I have to get the section names' list.
GetPrivateProfileSection(...) will return all section names as a null seperated list. Actually I need to get the length of this list.
This ini file is from an out side source, so I cannot expect the section names' count or size.
In this situation one method that I think to do is specify a very higher size ( about 32K ).
Could you please tell me your opinion about this?
Thank you.
- NS -
|
|
|
|
|
NS17 wrote: In this situation one method that I think to do is specify a very higher size ( about 32K ).
Could you please tell me your opinion about this?
This is very memory consuming. I would suggest to use my second method: Read in the key names using ::GetPrivateProfileSectionNames ( this give you only the names, with which you can retrieve the keys later) as long as the return value is equal to the size of your buffer minus two, and increase dynamically the size of the buffer at each step.
MSDN quote : If the buffer is not large enough to contain all the section names associated with the specified initialization file, the return value is equal to the length specified by nSize minus two.
~RaGE();
|
|
|
|
|
Ok... Thank you...
But what about the performance? I have no idea about how windows handles ini files...
- NS -
|
|
|
|
|
NS17 wrote: I have no idea about how windows handles ini files...
Ini files are now obsolete, replaced by entries in the registry. It was a normal text file, read in as a normal text file, and keys were searched for using normal string search functions.
Performance of course will highly depend on the size of your file and the number of entries in it. If you see that it requires too much run to get the approximative good size, increase the the size in each loop with higher size steps.
~RaGE();
|
|
|
|
|
Yes... fine...
Thank you very much!
- NS -
|
|
|
|
|
I actually like .INI files. Place an .INI file with settings in the application folder and you don't have to worry about orphaned registry entries when the application folder is deleted. If I'm writing a program I aim, within reason, to make it installable simply by copying files, uninstallable by simply deleting them and no littering of the system. Obviously this is not always possible or economical but it's a good aim as users, especially "non-expert" users, often try to uninstall an application by deleting the application folder.
Steve
|
|
|
|
|
You said it...
I am also like to do the same...
- NS -
|
|
|
|
|
NS17 wrote: I have no idea about how windows handles ini files...
While it is true that they are just text files, an API exists for reading from, and writing to, them. See the functions near the bottom of this link.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
Rage wrote: This is very memory consuming.
32KB is very memory consuming? Since when? Anything less than 1MB is trivial.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
NS17 wrote: It will store all the section names to lpResult. But how can I estimate the nSize...
Just allocate several KB and you'll be fine.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)