|
How can I programmatically make a button invisible?
I can enable or disable and I can go into properties and
make the button invisible (or visible), but how can I
make it invisible programatically at run-time?
Please, any response any one can give me will be
greatly appreciated.
Sincerely,
Danielle Brina (an overworked graduate student)
|
|
|
|
|
|
I have a dialog-based app that:
- displays an image in a picture control (CStatic)
- has a bunch of labelled text boxes (CStatic & CEdit)
- has a few other bits & pieces (CScrollbar, CComboBox, CCheckBox...)
The app needs to fill as much of the available screen real-estate on the computer running it. I can resize the main dialog window easily enough... but resizing the various controls on it looks like a tedious business.
It's a one-off. Am I just as well off doing the layout calculations by hand, and giving every text box label an ID other than IDC_STATIC to do it... or is there something there that will so dramatically reduce the pain of all this that it is worth learning. On the face of it, CResizableDialog is more effort than it's worth... but I stand to be corrected.
|
|
|
|
|
I believe there's a CP class that does this as well, but you'd have to have a look for yourself, I'm not sure.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
|
See the "Extras" section of this article.
"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
|
|
|
|
|
Thanks guys --- I ended up biting the bullet and doing it "longhand". One day I may refactor it into something like what was in David's "extras"... but it would take considerably more sophistication to cope with the kind of form layout I have --- lines with 3 or 4 edit boxes across the full screen needing to be resized proportionally in the horizontal direction, while their labels stay constant size; image "window" resized to take up the remaining space among the edit boxes & buttons...
|
|
|
|
|
That's what I do too, doing each control 'by hand'. I reckon it can give a much better appearance, as various things need different changes.
In fact, in some dialogs I even alter the layout as the size changes. It can be a bit of a pain to do, so it is worth doing methodically, and commenting clearly. It is easy to get into a muddle doing this kind of thing.
Oh, I also take screen images and load these into graphics software so that I can enlarge them enough to be able to count the pisels.
Shraddhan
|
|
|
|
|
Hello!
I got class CMyClass:
class CMyClass<br />
{<br />
private:<br />
CString Name;<br />
public:<br />
CString GetName() const;<br />
};
I want to make list of objects CMyClass, so I do:
typedef list<CMyClass> MyLst;<br />
MyLst MyList;
Now I want to make list of iterators to my previous list, so I do:
typedef list<MyLst::iterator> pMyLst;<br />
pMyLst pMyList;
Let's assume I have some elements in list MyList and I want to fill list pMyList with iterators from MyList list:
for (MyLst::iterator it = MyList.begin(); it != MyList.end(); it++)<br />
pMyList.push_back(it);
Now I would like to retrieve some data from my iterator list, and I do:
for (pMyLst::iterator it = pMyList.begin(); it != pMyList.end(); it++)<br />
{<br />
CString Name;<br />
Name = (*it)->GetName(); // program crashes here
}
Help!
|
|
|
|
|
Mateusz Karbowy wrote: (*it)->GetName();
You didn't store pointers, so why are you using -> instead of . ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
He stored iterators, which are conceptually very similar to pointers. (*it) gives the iterator he stored and (*it)-> returns the object referred to by the stored iterator.
Steve
|
|
|
|
|
I don't think that is true. In any decent compiler, you may not treat an iterator as a pointer, and once you dereference the iterator, you get the object you stored, not a pointer to it.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
typedef list<CMyClass> MyLst;
A list of CMyClasss
typedef list<MyLst::iterator> pMyLst;
A list of iterators into a MyLst
pMyLst pMyList;
Contains list<CMyClass>:iterators ("expanded" typedef).
(*it)->
Calls operator-> on a list<CMyClass>::iterator
Steve
|
|
|
|
|
Stephen Hewitt wrote:
Calls operator-> on a list<CMyClass>:iterator
OK, I get it now. The problem is that there's a list of lists here. I didn't spot that. I *never* use typedefs with STL for this reason, it just obsfucates the code.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I don't believe a list of iterators is the right approach. Why would you store iterators, instead of the underlying objects ? Store pointers to your class, if you want them to point to the same object.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I can't see anything wrong with your code. Perhaps attach crash details. I suspect the problem is not in the code you posted but somewhere "in between". For example - maybe the element is removed from the list somewhere.
Steve
|
|
|
|
|
Thank you Steve and Chris. You're right Steve, this code is ok. I've spotted the problem in a different place and now it works fine. Thanks for support mates! 
|
|
|
|
|
Hi, I have a solution with some projects that produce dlls. However some of these projects also generate a .lib file for their respective dll in order for another project to link with dll at linking-time. However some other dll projects do not provide me a .lib file. Why does this happen?
At first I thought I missed an option at the property page of the latter projects but this is not the case, as I compared the property pages finding no such differences.
What should I do in order for all my dll projects provide me with a lib file?
Thank you.
PS - I'm using VS2005
|
|
|
|
|
Typically, this means that you are not exporting anything from the DLL. Is that the case?
Regards,
Nish
|
|
|
|
|
Yeap actually that was the case, I forgot to export the symbols. Thanks for the tip, I could have gone days without realizing it.
|
|
|
|
|
Hi,
I attach an image list to the CHeaderCtrl with a call to CHeaderCtrl::SetImageList.
Later I use CListCtrl::SetImageList to attach an image list to the CListCtrl object used for the items.
The 2 image lists are different. Every time I call CListCtrl::SetImageList my image list of the
header control gets overwritten with that of the list control.
Is this a bug ?? or is it impossible to maintain 2 different image lists.
Thx
|
|
|
|
|
|
I have installed an OnSetImageList message handler for the header control. THis one gets called when an image list is installed for the header control and it gets called a second time when the CListctrl object is assigned his image list. To install the image list of the header control I do the following call from within the OnCreate message handler of a derived CListCtrl Object (CXListCtrl) :
m_HdCtrl.SetImageList(&m_ilSymb);
m_HdCtrl has been subclassed to the Header control.
To install the image list of the CListCtrl object itself I do the following call in the OnCreate handler of a CXListCtrl derived class. (CPCntCtrl)
SetImageList(&m_ilCntSymb, LVSIL_SMALL);
Can someone tell me please what is going on here ?
Thx
|
|
|
|
|
I have a List control where sometimes I want to limit it to a single selection and other times to multiple selections.
You choose the Single Selection parameter at design time, but I'm sure there must be a way to change in on the fly. It is most like a SENDMESSAGE, but what is the message I need to send?
Thanks,
Ilan
|
|
|
|
|
hi ,
Try SetWindowLong Function .
Regards
FarPointer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)