|
Hi,
I wanna change the current font in a EditView with CFont Dialog.
I have placed the following lines in my code:
void CMainFrame::OnFont()
{
CMyDoc* pDoc = (CMyDoc*)GetActiveDocument();
LOGFONT logfont;
CFontDialog fontdlg;
if (fontdlg.DoModal() == IDOK)
{
pDoc->m_Font.DeleteObject();
pDoc->m_Font.CreateFontIndirect(&logfont);
POSITION pos;
pos = pDoc->GetFirstViewPosition();
CMyEditView* pMyEditView;
while (pos)
{
pMyEditView = (CMyEditView*)pDoc->GetNextView(pos);
if (pMyEditView->IsKindOf(RUNTIME_CLASS(CMyEditView)))
pMyEditView->Invalidate();
}
}
}
and
void CMyEditView::OnDraw(CDC* pDC)
{
CDocument* pDoc = GetDocument();
CEdit* pEdit = &GetEditCtrl();
pEdit->SetFont(&pDoc->m_Font);
pEdit->SetWindowText("My Text");
}
It does not work and dunno why.
Thanks for your help.
R.
|
|
|
|
|
Don't you need to call CEditView::OnDraw from CMyEditView::OnDraw ?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I have generated an empty project but there is no such call
|
|
|
|
|
Sort of. I've investigated a little further: CEditView derives from CCtrlView , which adds its own WM_PAINT handler bypassing further calls to OnDraw . So, if I'm not wrong on this, CMyEditView::OnDraw is never called (you can confirm/refute this). Move the SetFont to somewhere else (one good candidate is the very body of CMainFrame::OnFont .)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
OnDraw was really not called (put a AfxMessageBox and no response).
Works perfectly.
Thank you very much.
R.
|
|
|
|
|
Hi,
I have a simple SDI CView in the client area of my mainframe and wanna create a splitterwindow in its bottom only when a button is pressed (and destroy it after usage).
My problem is that a splitterwindow is meant to be created in the CMainFrame::OnCreateClient which creates the splitterwindow "forever" even when I don't want it.
What is the solution?
Thak you.
R.
|
|
|
|
|
Check here under MFC controls, splitter windows...
I think there are some classes that allow easy construction of dynamic splitter windows.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I sould post again the question, in another light:
If C++ is an OO program, why compiler doesn't provide automaticaly a default program entry point, if it is not provided by programmer?
There are compilers that do this? Which one?
Is a way to make Visual C++ compiler to do this?
Does anyone know something about so called "nostub" programs?
Regards
|
|
|
|
|
If C++ is an OO program, why compiler doesn't provide automaticaly a default program entry point, if it is not provided by programmer?
IMHO, the object-orientation of the language has little if anything to do with the automatic provision of an entry point for a program.
There are compilers that do this? Which one?
None that I know of. It would be against the standard, which very clearly specifies how an entry program is to be provided.
What is that you're after? If you explain yourself a little longer, maybe we'll be able to help you.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
My problem is that in MFC, program entry point is encapsulated somewhere in a class. (Or maybe my understanding is wrong here??). I want to do the same, and have no global function in my application.
Thanks.
|
|
|
|
|
Don Miguel wrote:
why compiler doesn't provide automaticaly a default program entry point
It does, it's main() or WinMain().
--Mike--
"There are only a limited number of jobs where they will ask to see the sausage. Most of them are in movies."
-- Christian Graus, 2/11/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
Michael Dunn wrote:
It does, it's main() or WinMain().
If I don't put main() in my code, the linker tell me about an unresolved symbol, so, IMO the compiler doesn't provide what I need.
|
|
|
|
|
What is the purpose of your application to not have an entry point?
If you do not have a global entry point, there is no way for your code to start executing.
|
|
|
|
|
kilowatt wrote:
What is the purpose of your application to not have an entry point?
Really, I agree with ideea to have an entry point, but I want this entry point to be a member function of a class, and not a global function.
|
|
|
|
|
In order to get that to work, your entry point function will need to be a static function of the class, because your class will not yet be initialized when your program starts up.
Then you will have to find the compiled symbol for that static class function and set this into the the entry-point symbol field of the ouput category on the linker page of Project settings.
Finally you will need to initialize the C/C++ runtime library yourself if you plan on using printf, cout, the string functions and things like this. You should be able to find some articles in MSDN or on the internet that explain how to do this.
Here is a sample program that I wrote to test this:
<br />
#include "stdafx.h"<br />
<br />
class entry<br />
{<br />
public:<br />
static int point()<br />
{<br />
return 0;<br />
}<br />
<br />
};<br />
<br />
int main(int argc, char* argv[])<br />
{<br />
entry::point();<br />
<br />
printf("Hello World!\n");<br />
return 0;<br />
}<br />
The entry point that I used was this: ?point@entry@@SAHXZ, I found it in the disassempbly when I called entry::point from main before I reset the entry point.
If you have any more questions feel free to ask.
|
|
|
|
|
Thanks a lot! Youre answer bring a lot of light to me.
Everithing you say is right, I tested the snippet you show me.
I must say it work for me without check entry point in disassembly, but putting in project settings->link->output->entry point symbol directly the function, "point" (without specification of class, "entry").
I make another try, to delete "static" qualifier for function "point"
and, everything work again!!! This really amasing me, since I am totally in agree with you that the function must be static.
Removing "static" and trying to use something like "this->aFunction" work also, and I was curious where point this, so I break program and look at the addresses. It point somewhere in an unknown zone, but invocation of entry function in form "this->point" continue to work!! Amazing, I think the compiler do something hydden, here. (I use VC++ 6.0)
Thanks for your answer.
|
|
|
|
|
It's not terribly mysterious. point is a member function of a class so it may be called and executed. However, no actual instance of the class has been created when it is called. If you add some data members you should see that they have not been initialized. Set up a constructor for the class to initialize the data members and you should see that it is never called.
|
|
|
|
|
Yes, you are right, the class is not initialized,
but, the amazing fact is that calling another function
from the class, through "this" pointer work!!!!!
Is like a virtual table exist, for a class uninstantiated!!!!
- maybe I should verify this with another compiler!!
|
|
|
|
|
You really will want to make your entry point function a static function, unless there is no member variables in your class, then it wont matter.
The function V-Table always exists for a C++ object, that is why your non-static member function succeeded, however, the moment that you try to use a member variable from this function, without an instantiated object, your program will crash because no memory has been allocated to this object, and there is no valid this pointer sent into the function.
If you were to try this example with teh get_data member funtion as the entry point, it would crash on you:
<br />
#include "stdafx.h"<br />
<br />
class entry<br />
{<br />
int m_data;<br />
public:<br />
static int point()<br />
{<br />
return 0;<br />
}<br />
<br />
int get_data()<br />
{<br />
return m_data;<br />
}<br />
<br />
};<br />
<br />
int main()<br />
{<br />
entry::point();<br />
<br />
entry x;<br />
x.get_data();<br />
<br />
return 0;<br />
}<br />
With this is mind, your static member function should instantiate a class object for you to continue with your plans.
|
|
|
|
|
kilowatt wrote:
The function V-Table always exists for a C++ object, that is why your non-static member function succeeded,
Thanks, I doesn't know this. So, no misterys here!
kilowatt wrote:
however, the moment that you try to use a member variable from this function, without an instantiated object, your program will crash because no memory has been allocated to this object, and there is no valid this pointer sent into the function.
You again are right.
So, my questions are clear now. Thanks a lot for your patience.
Regards.
|
|
|
|
|
Well, someone here recently remarked that its better to speak up and find out you're wrong and learn something...
I was testing with just a global foo() fn, and had to force linkage if I removed main, but I see now this can work.
I wasn't able to track down anything on the ability to manually initialize the c runtime though, and would like to know if thats possible. FWTW I did stumble on a '96 MSJ article by Matt Pietrek where he outlines how to _avoid_ using the CRT - search for TINYCRT in MSDN - win32 routines are used instead.
|
|
|
|
|
I am concerned about the following:
As long as in the linker options, I can set the program entry point,
and - I tested personally - this can be any function, with any prototype
(I mean not just main standard prototype), I wonder if is a way to set
as entry point a function with prototype like
AClass myClassInstance;
i.e a class type (user defined data type).
I put the question because I couldn't remember where I found a topic about
the fact that C++ doesn't really need main() function to work (was certainly
a discution about OO Programming and OO nature of C++)
Can anybody help? Does anyone know something similar?
Regards.
|
|
|
|
|
C++, like C, requires a main function for its entry point.
Yes, you can put a different function in the linker settings but I think its ignored for executables unless its just a question of resolution (i.e. wWinMainCRTStartup for unicode windows apps).
The key here is that you're linking with a standard runtime library (CRT) that has startup and exit code that will call your main routine after certain operations are performed (init static vars etc).
The 'nostub' programs you speak of are built with non-standard libraries and are I think targeted at embedded code that wants to bypass certain lib code for compatibility reasons.
It should be said that the reason for main is to maintain (no pun) the ability for C programs to be compiled. Would you rather go with a java construct where the 'main' class contains a defined entry point? Or is that still a restriction? I won't fight you if your argument is that that is more 'object oriented' - but until I get smarter that Stroustrup (note, I've almost got his hairstyle ) I'll try and deal with it.
|
|
|
|
|
I need a file open dialog with the following attributes:
#1 - Floppy drive access disabled.
#2 - Drag & Drop disabled within the file/folder list(s).
#3 - Context sensitive menu disabled.
#4 - Runs on Windows 95/98/Me.
Can this be done with the standard Microsoft CFileDialog class? If so, how? (I've read several CFileDialog sub-classing articles and none provide any clue to any of these issues.) If this is not possible with the standard dialog, does anyone know of a class that provides this functionality so I don't have to re-invent the wheel?
If anyone is interested in why I need this, read below...
Concept - My application is a control for a piece of industrial machinery. It provides a GUI to the operator as well as machine logic and high speed messaging with proprietary motion control modules for the machines axes. It runs on an industrial PC with a flat panel touch screen and a Texas Industrial pointing device. The operator needs to load new program files for each piece of raw stock that comes to the machine. Right now I am using the standard CFileDialog and have the following problems:
#1 - Floppy drive access is very slow and drags down system performance, when this happens the proprietary motion control modules' watchdog timers time out and shutdown the control. We tell everyone not to use floppies directly in the control software, but some never learn and I'd like to stop them.
#2 - Because the touch screen and industrial pointing devices are... well... industrial, they don't provide a good high resolution consistent method of handling smallish items (like files/folders in a CListCtrl) and heavy-handed operators accidently drag files/folders and drop them into other folders and lose them.
#3 - The machine operators have no need of the items in the context sensitive menu and can only get themselves in trouble with these commands. I'd like to eliminate the possibility.
#4 - Unfortunately the drivers for the proprietary motion control modules run ONLY under Windows 95/98/Me and many of our current machines in the field are running Windows 95, so any solution MUST run on it.
Problems #2 and #4 are the most important, #1 and #3 are icing on the cake!
Mike Mullikin
"Programming is like sex. One mistake and you have to support it for the rest of your life." - Michael Sinz
|
|
|
|
|
I'd craft my own, using a combo box of hard disks, a folder listbox and a files list box, much like the old style File Open dialog. You can also auto-filter for files of a specific type that make sense to your app.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|