|
sorry. I ment msdn.com not mdn.com also, if you ar running v.s. 6.0 PARAFORMAT may be the structure to use...
RRL
|
|
|
|
|
Much thanks, I'll take a look.
--hsm
|
|
|
|
|
I just looked. Two problems occur to me; first, this is for a CRichEditView, not a CEditView. The other problem is that this would allow control of the space above a paragraph--- not the space above the page. Perhaps I'm missing something?
--hsm
|
|
|
|
|
For those with the same problem, a tentative answer is to set the rectangle in the CEdit control:
void CPGNTextView::SetTopMargin()<br />
{<br />
CEdit &theEdit = GetEditCtrl();<br />
CRect r;<br />
theEdit.GetRect(&r);<br />
TRACE("t=%d l=%d b=%d r=%d\n",r.top,r.left,r.bottom,r.right);<br />
r.top = TOP_MARGIN;<br />
theEdit.SetRect(&r);<br />
TRACE("t=%d l=%d b=%d r=%d\n",r.top,r.left,r.bottom,r.right);<br />
}
And then to do it again in WM_SIZE and WM_SETFONT handlers. Seems like overkill, but the CEdit control loses this information every chance it gets so you just have to help it along so to speak.
--hsm
|
|
|
|
|
Is there a way I can do something like this:
<br />
class MyClass<br />
{<br />
...<br />
private:<br />
class MyInnerClass: public CWnd<br />
{<br />
...<br />
afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);<br />
afx_msg void OnShowWindow(BOOL bShow, UINT nStatus);<br />
...<br />
};<br />
...<br />
};<br />
??
I've been trying for a while, and the code doesn't even compile (if I declare the class outside the first one, everything works OK, but I want the class to be inner). I suspect it's a matter of names for the message maps, but can't figure out the right one...
Thanks!
Alberto.
|
|
|
|
|
Why do you feel the inner class is necessary?
I would probably have done this instead:
class MyInnerClass: public CWnd<br />
{<br />
...<br />
afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);<br />
afx_msg void OnShowWindow(BOOL bShow, UINT nStatus);<br />
...<br />
};<br />
<br />
class MyClass<br />
{<br />
...<br />
private:<br />
MyInnerClass* m_InnerClass;<br />
...<br />
};
And avoid the entire problem.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
It's what I've done, but I feel the inner class is necessary for preventing unnecesary access to it.
I just wanted it to be sort of "private", and it seemed to me it was the best way (ok, i admit it...I'm a java programmer).
Thanks for the answer (sorry for my english)...
Alberto
|
|
|
|
|
If you really want to hide the internals of your class, then
make a forward declaration like this:
class MyInnerClass;
then use it privately in some other class:
class SomeOtherClass
{
...
private:
MyInnerClass* m_MyInnerClass;
...
};
and then declare the MyInnerClass in the source file along with its implementation as the same source file as SomeOtherClass and only SomeOtherClass will ever be able to actually 'use' the MyInnerClass.
Or, just declaring the pointer to it like the original example, that pretty much prevents ANYTHING else from using the MyInnerClass anyhow.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
|
I've tried it, and didn't work (maybe I missed something elsewhere).
Thanks.
|
|
|
|
|
|
johni__boy wrote: Can anybody help me please to find out the bugs in the folowing code . The code doesnt contain any syntax errors but still it doesnt run .
It would be more appropriate if you found the problematic code (i.e., bug), and then ask us what is wrong with it. Asking us to search through a bunch of code to find out what is wrong is not what we (most of us at least) are here for. Narrow your code down to just a few statements and you'll get way more help. 
For starters, calling findnumber() with NULL as the second argument will result in a problem when you go to dereference the pointer. The code you have to add a new number to the list is wrong.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
thanks for your comments, probably you are right.
The second argument by calling findnumber() is not Null but it is used to access to the structure :
typedef struct entry
{
int number; // our entry
int freq; // how often we've seen it
struct entry *next; // pointer to the next item
} entry_t;
I don't understand how is the second line of the input text is loaded in the buffer and what number we are adding to the list.
|
|
|
|
|
johni__boy wrote: The second argument by calling findnumber() is not Null but it is used to access to the structure :
Initially you set entrylist = NULL; so the first time you call the findnumber function the second argument is NULL. So in the findnumber function you should first check to see if the second argument named "list" is NULL, and if it is, you should return NULL.
Now, look at the last two lines of this block and imagine adding the first node into an empty list.
else
{
// no, create new one.
entry = (entry_t*)malloc(sizeof(entry_t));
entry->freq = 1;
entry->number = number;
entry->next = entrylist;
entrylist = entry->next;
}
1. again, initially entrylist is NULL
2. you create a memory block to hold a node and the next pointer is pointing to entrylist which is NULL. ok
3. entrylist should point to entry not entry->next.
I don't know if there are other problems, but that's what I see without compiling the code. You should learn to use breakpoint, the stack trace, and the watch window because these problems can be easily spotted.
|
|
|
|
|
looks like homework to me....
onwards and upwards...
|
|
|
|
|
Why make a linked list manually? Use a std::list and your bugs disappear and the program shrinks down to a handful of lines. Unless of course it's a learning exercise or even (gasp) homework.
Steve
|
|
|
|
|
I need to register IITAPIEventNotification interface in order to proces events. For that I need a callnot.h and callnot.cpp files, but I don't have them. How can I get them?
|
|
|
|
|
Greetings:
I am trying to experiment with making an application with flexible windows that show different things and can be opened and closed at will and in no particular order. I do not want to involve the document / view architecture. There's no need for an underlying document; my program receives input data from external ports of various kinds.
For openers, I tried to create an SDI application with no Doc/View but whose client is a CFormView, not a CChildView. Why is this hard?
Should I REPLACE the CChildView client window with a CFormView? Or, should I create a CFormView and then derive the CChildView from the new CFormView (instead of from CWnd as the App Lizard would have it)?
I have a metric tonne of books on the subject of programming in MFC and I have yet to encounter one, just ONE, that clearly explains and lays out the architecture of SDI, MDI, Doc/View, non-Doc/View, splitters, CMainFrame, Views, etc, etc. I would like to understand these things in such a way that I can finally feel that I have some measure of control and choice as to how my application windows behave and can write a program that breaks from the straight jacket that is the MFC App-Lizard. Has anyone out there encountered a book or resource that does this? I mean, explain it to me like I'm 4 years old! Insult my intelligence! Just make it clear!
There, I feel better. Thanks in advance to anyone who responds.
Cheers,
Mark
|
|
|
|
|
Jethro63 wrote: my program receives input data from external ports of various kinds.
Why would this preclude the use of Doc/View?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Hi David:
It doesn't necessarily, but MUST I always use Doc/View? I find that I create my application using doc/view and the "doc" component of it goes unused. Then I find it just gets in my way when I want to do something like replace one view with another, or add a new view.
Its the principle of the thing really. Can't you just put up a main frame and then throw up whatever child windows you want, when you want without having to deal with all this doc/view baggage?
Thank for your response.
Mark
|
|
|
|
|
Jethro63 wrote: Then I find it just gets in my way when I want to do something like replace one view with another, or add a new view.
In this situation, what is the view displaying?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Could be anything. Let's say I'm connected to a specialized piece of equipment and it is sending messages asynchronously through the USB port to my application. I want to offer my user 3 or 4 different ways of viewing these incoming messages: raw hex data, a scrolling list view, a graphical histogram plot, a statistcial listing. The user should be free to open, close and arrange any number and combination of these windows. At the same time, maybe I would like a "Console Window" where the user enters synchronous commands and the response from the device is displayed in the same window. Still another window (like a form view) that contains push button controls, sliders, edit boxes that handle other types of commands to the device or to the application to control its behavior. I might also want the option to turn on a diagnostics window where special program messages get directed to.
I see that all of these windows involve data and I suppose that you could make it fit into the doc/view paradigm if you had a crow-bar and a sledge hammer, but I don't see how it helps me to use a doc/view based approach. I don't use serialization, I am used to saving data in files using old-fashioned read and write commands to an open file pointer. In the end, I always find that the doc/view needs a doc/view template and then I can never figure out how to open up more than one view for the same document data or create an alternate doc/view pair and it all gets way too complicated way too fast.
That's my story. Any suggestions would be welcomed.
Mark
|
|
|
|
|
  :
1. Create a new MFC AppWizard (exe) project.
a. MFC AppWizard - Step 1 of 6
i. Select "Single document" for the application type.
ii. Uncheck "Document/View architecture support?".
b. MFC AppWizard - Step 2 of 6 - no changes
c. MFC AppWizard - Step 3 of 6 - no changes
d. MFC AppWizard - Step 4 of 6
i. Set the number of files on the recent file list to 0. (optional - no MRU anyway)
ii. Press "Advanced..."
1. Uncheck "Thick frame" and "Maximize box", leaving only "Minimize box" and "System menu" checked. (optional)
e. MFC AppWizard - Step 5 of 6 - no changes
f. MFC AppWizard - Step 6 of 6 - no changes
2. Create a CFormView for the application.
a. Select Insert->New Form....
b. Enter a form class name in the "Name" field, e.g. "CMyFormView".
c. Press OK.
d. Design the form as desired.
3. Adjust command handlers in new CFormView-based class.
a. Using the ClassWizard, insert a handler for OnInitialUpdate.
b. Add the following code into the OnInitialUpdate handler where indicated:
GetParentFrame()->RecalcLayout();
ResizeParentToFit();
4. Remove ChildView.h and ChildView.cpp from the project. Delete the files.
5. Remove CChildView references from MainFrm.h
a. Remove the "#include ChildView.h" directive.
b. Remove the "CChildView m_wndView" member.
6. Adjust command handlers in MainFrm.cpp
a. Remove the OnCmdMsg handler and delete its code.
b. Remove the OnSetFocus handler and delete its code.
c. Edit the OnCreate handler
i. Remove the view creation code:
if (!m_wndView.Create(NULL, NULL, AFX_WS_DEFAULT_VIEW, CRect(0, 0, 0, 0), this, AFX_IDW_PANE_FIRST, NULL))
{
TRACE0("Failed to create view window\n");
return -1;
}
ii. Remove the docking capability for the toolbar by commenting out or deleting the indicated lines. (optional)
7. Adjust application creation in <appname>.cpp
a. Include the view class header, e.g. "#include "MyFormView.h".
b. Edit the InitInstance function
i. Replace the frame loading code:
pFrame->LoadFrame(IDR_MAINFRAME, WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE, NULL, NULL);
with the following code:
CCreateContext oCreateContext;
oCreateContext.m_pNewViewClass = RUNTIME_CLASS(CMyFormView);
oCreateContext.m_pCurrentFrame = pFrame;
pFrame->LoadFrame(IDR_MAINFRAME, WS_OVERLAPPEDWINDOW, NULL, &oCreateContext);
pFrame->InitialUpdateFrame(NULL, TRUE);
Everything should compile okay. N.B. when you run the application in debug mode, you will receive "Warning: Creating a pane with no CDocument." in the debug output. It's a nice warning, but that WAS kind of the whole point, right?
--
I've killed again, haven't I?
|
|
|
|
|
Hi "Office Lineman":
I lost track of this thread and did not discover your response until today. Thank you very much for your instructions. I normally respond right away when somebody takes the time to answer a question that I post, so I feel a bit embarrased that I missed this, especially since it is clear that you spent some time on this response.
I followed your instructions and they worked exactly as I had hoped. I was a bit puzzled by the final segment where the "CCreateContext" structure is brought in. After reading up on this structure, I see that most of its fields can be regarded as optional. This has lead me to an example on the MSDN DVD called "VIEWEX" which expands more on the problem that I originally pointed out: It is not obvious or straight forward how to create an application that consists simply of a main frame which can house a variety of different views, opened or closed in no particular order. I have been searching for a general understanding of all of this and it is difficult to get the answers I am looking for.
Anyway, thanks again for your instructions.
Mark
|
|
|
|
|
This is absolutely awesome. Thank you so much for posting this! I've been going crazy trying to figure it out.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
