|
If you use icon for regular CButton class it cover the button text,there is two solution
1.use CBitmapButton,but its painful.
2.subclass CButton and draw it your self,like the buttons in CP,
I suggest you use one of buttons in CP,they are really perfect.
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
The button is not CButton, just a ToolBar button. 
|
|
|
|
|
What styles are you using in creation of the toolbar? AFAIK, the BTNS_SHOWTEXT button style is only useful when the toolbar has the TBSTYLE_EX_MIXEDBUTTONS style; it is unnecessary if you want to display the set text for all your buttons.
farewell goodnight last one out turn out the lights Smashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
I remove BTNS_SHOWTEXT flag,but it doesn't work also.
I want to create a toolbar like IE with adding button dynamicly.
|
|
|
|
|
Nothings coming to mind i'm afraid... Are you making sure to add all the buttons before the toolbar is first shown?
If you'd like to send me the code you're trying to use, i'd be happy to take a look at it.
farewell goodnight last one out turn out the lights Smashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
Or must I use that from C Runtime Library.
I looked at lstr... functions in docs but didn't find any suitable.
|
|
|
|
|
What is wrong with using CRT ?
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
I am just trying avoid linking with static library whenever I can link with system DLL (the case of WinAPI functions). Static linking enlarges my exe file, and this is the only cause I am looking for equivalent.
|
|
|
|
|
To the best of my knowledge there's no equivalent API to strrchr (nor to strchr BTW). But writing your own versions to avoid linking the CRT is extremely easy.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
It's really easy if you use the CRT source code (strrchr.c) 
Gavin
|
|
|
|
|
|
Where did this UFO come from? ...go MSDN to do some search... it's in the shell library! Good catch, Nish! The only caveat of this function is that its base line is Win95+IE4.0. For those who care about maximum platform support this could be a problem.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
|
Hi !
RPC is not realy supported under windows CE, but I need to create uuid (on desktop applications, I'm using UuidCreate).
How may I do ?
Emmanuel Derriey
|
|
|
|
|
Dear all,
I need to write an program just like the resources meter in Win 95, which will look on the system resource, include GUI heap, User heap, etc to get a rough estimation of the free system resources. Such program will be run on win9X.
Is there any API/Class can I use.
Thx. 
Marco Hung
|
|
|
|
|
Hi.
I began and finished reading chapter 9 of Promise's book on MFC today. I believe I have reached a milestone in the journey to become a proficient...good MFC programmer.
Here is what I know.
MFC = application object->frame window->view->documents
Promise emphasized that documents as an abstract concept object including data. I interpret documents as dealing with the program's "purpose" i.e. program theme.
Nonetheless, I have not come to a complete understanding as to what comes first: view or documents. For example, as program designer and developers, we should always walk the steps of a program user. I am not completely sure as to where is the clear separation of view and documents, event though view is the program interpreter. View does the drawing according to the data from documents.
For example, let say I am working on a program that reads data from a file and puts it on a window in *binary* mode. Let say I create three classes using AppWizard and ClassWizard:
1) ConceptPro (mainframe window)
2) view
3) document
First, the classes above are MFC's generated classes.
Conception is the application object and it handles all the taskbar, menu, etc.
View draws the childframe, *binary* data from a file, etc.
Documents handles the data such as filename, file data, etc.
Is the description above valid? Please point out where I am "going off track" or "missed something important."
Lastly, let say I have other classes that manipulate the data in the file *before* outputing it. Where should I instantiate these classes in documents or in view? I am not completely clear as to rank of document and view.
Thanks,
Kuphryn
|
|
|
|
|
IMO I believe that the Document should be designed first. It is possible to create multiple views of the same document. In fact, each of these views can display some different aspect of your document. Therefore, because the Document is the item that all of the views have in common, the document is the object that should be designed first.
It may be useful however, to take into account what you want your view to display, this may give you some clues as to the types of data that may be required in your Document object, but may not be immediately apparent.
kuphryn wrote:
Lastly, let say I have other classes that manipulate the data in the file *before* outputing it. Where should I instantiate these classes in documents or in view? I am not completely clear as to rank of document and view.
Here is an attempt to create a quick diagram of a clean design for what you have described.
This is not an inheritance model, but a model of the owners of all of the objects. The arrows
point to the child objects that a parent object owns.
--------------------------------------------------
| |
| Main Window |
| |
--------------------------------------------------
| | | |
| | | |
| | | |
V | V V
------------ | ------------- --------------
| View 1 | | | View 2 | | Document |
------------ | ------------- | Mutator |
| --------------
|
V
----------------
| Document |
----------------
In this diagram, all of the objects are owned by the main window, the simply point to the document, and use the data in the document. View the Document as a piece of data with accessor functions.
With this in mind then you will need other classes that manage the data (document mutators), whether you edit it with an edit control or some other method. These items should be owned and controlled by the main window / main module. This allows the data to be separated from the implementation. This design would also allow you to reuse the document object that you created in a completely different app with a completely different front end (optimal code resue).
While I know that this is not always the final result in the practice of software engineering, it is a main goal of object oriented software design.
|
|
|
|
|
Thanks.
Your diagram is clear.
Also, how about determining where to include command and command handlers, including updates? If I remember correctly, Promise emphasizes any commands having to do with the mouse and keyboard should be in view.
MFC is very powerful. Microsoft designed MFC to be flexible. For example, I was not clear as to how a view object knows when to draw an interpretting of document data on the screen. I believe documents calls friends classes of view. That is flexible.
Kuphryn
|
|
|
|
|
Your right, besides displaying the document, the views other purpose is to manage the UI commands that relate to the document through that view.
Deciding where the command handlers should go can be tricky, I think that it all depends on whether you want your design to lean towards the conceptually perfect object-oriented design, or the completely function software implementation. I think that it is best to create an implementation that is somewhere in the middle.
What I mean by this, is the line gets a little blurry where certain members should actually be placed. I think that in most cases, especially programs with simple views, the handlers, and mutators can be placed directly in your view class.
The fact is that most of the sample programs that you find in books are small, and the authors develop their samples with this technique. When you start getting larger projects, possibly with multiple views, and events that have alot of common code, this is when you should start breaking your classes down and creating the mutator classes that I spoke of earlier.
Hope this helps, it is simply my opinion, but my opinion is based on years of experience and alot of reading of other peoples opinions and experiences.
|
|
|
|
|
kilowatt: Thanks! Yeah, I could foresee that it could become difficult to pick where command UI handlers should be. When you said OOP concept, are you implying command UI being in view or in documents? I believe OOP is extremely powerful because the concept related to real life.
As I mentioned in the topic of "New Milestone," document/view architecture has shine light on my understanding of MFC. It gave me confident to push further (finish the book), and along the way, begin to take pay close attention and take notes for future projects (implement my C++ programs using MFC). I am not quite to that point yet, but MFC is beginning to come together nicely relative to my learning MFC.
-----
Multiple view per document: (AsmGuru62 brought up this issue at programmersheaven)
Lets consider the example AsmGuru62 mentioned about formatting data in text and HEX. As of chapter 10 in Prosise' book, he has not brought up the concept of multiple view. He did mention multiple documents as an upcoming topic, but not multiple view.
First, for multiple view, do you approach it exactly the same way as singular view? Do you use ClassWizard to add a new a new derivative of CView or one of CView's derivative (scroll, etc.)?
-----
I am at a point with MFC where I see the *lego* pieces, but I have limited experience assembling the pieces together. That includes mapping related commands to related class derivatives, etc. I believe that comes with experience.
Kuphryn
|
|
|
|
|
if (Promise == Prosise) goto WinAPI;
|
|
|
|
|
little question:
i am using an ifstream and getline like this
while (1)
{
if (!std::getline (file, line1))
break;
}
well.. this works very well.. but some of the textfiles i'm reading don't have got CR+LF in their last line.. means that this call returns false.. and that i am missing the last line.
can somebody explain me how to do this correctly or a workaround?
Sometimes I think the surest sign for intelligent life elsewhere in
the universe is that none of them ever tried to contact us.
|
|
|
|
|
I'm not able to reproduce your problem. This tiny program
#include <string>
#include <fstream>
#include <iostream>
using namespace std;
int main()
{
ifstream in("test.txt");
for( ; ; ){
string str;
if(!getline(in,str))break;
cout<<str<<"LF"<<endl;
}
return 0;
}emits the same output no matter whether the last line of test.txt is CR+LF terminated or not.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
yeah.. it really works.. so i've cut out the original code.. cause it is a little bit more complex.. but i thought i cut it down to the "root of its evil"
while (1)
{
if (!std::getline (file, line1))
break;
std::streampos here = file.tellg();
std::getline (file, line2);
file.seekg (here);
....
}
well.. the code is something like 2 steps forward, one step back.. i use this because i need the context of every single line in the text file..
it works perfectly for text files where the last line is terminated with CR+LF, but if the file is not terminated with CR+LF it breaks when reading this line.. and not when the EOF is reached..
thanks in advance
bernhard
Sometimes I think the surest sign for intelligent life elsewhere in
the universe is that none of them ever tried to contact us.
|
|
|
|
|
This patch seems to fix the thing
while (1)
{
if (!std::getline (file, line1))
break;
std::streampos here = file.tellg();
std::getline (file, line2);
<font color=#ff0000>file.clear();</font>
file.seekg (here);
....
}But my impression is that the code should work without the patch... maybe it's an STL bug. I'll do some more investigation later.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
