|
work_to_live wrote:
the dialog window does not exist anymore whan DoModal returns
100% correct.
handle OnOK in your dialog, in it, grab the LB value and store it in a member variable. when DoModal returns, grab the value from the member variable.
-c
“If it turns out that I’m actually the one who did it, then looking for the real killers would be a big old waste of time.”
-- OJ Simpson
|
|
|
|
|
That's close to what I did, and it worked... Seems like a lot of work, but if that what it takes... that's what it takes.
Here's the code that set up the dialog box...
// Iterate through the doc template
POSITION pos=GetFirstDocTemplatePosition();
CDocTemplate *pDocTemplate=GetNextDocTemplate(pos);
pos=pDocTemplate->GetFirstDocPosition();
// Instantiate the Document List dialog class
CdlgDocList SelectDoc;
while(pos)
{
// Get a pointer to the document
CDocument *pDoc=pDocTemplate->GetNextDoc(pos);
// Add the document's name to the Dialog's combobox
SelectDoc.AddString(CString(pDoc->GetTitle()));
}
// Execute the modal dialog box
SelectDoc.DoModal();
// Make a copy of the selected doc name
CString temp=SelectDoc.SelectedString;
The AddString function loaded up a CString array in the dialog class. Then, in the dialog class, I over-road OnInitDialog, and copied the array of CStrings to the ComboBox. Then I over-road DestroyWindow, and prior to destroying the dialog window, I copied the selected string to a public CString of my dialog class. Then as you mentioned, after DoModal returned, I could retrieve the string from that public CString member.
Seems like a lot of work for something so simple!!!!
Thanks for the help.
|
|
|
|
|
First and formost...I hope I don't get chewed out for not posting this in STL/ATL/WTL forum, but I figured this question was suitable for this forum also... 
I need a specialized circular queue, so i'll give the requirements and maybe you can tell me if this functionality already exists in STL or something (I don't care for UNDO/REDO systems available on CP, i've buily my own and their to flexible for this purpose )...but I think i'm gonna have to start from scratch...
1) Linear array of bytes(vector???) using new/delete, NOT lists
2) Must be able to specify size(s) MIN and MAX
- Min is the minumum incremental size and starting size of queue (actually it's an item count)
- Max is how large the queue can grow. Each time Min is reached the queue is expanded by Min+=Min
3) Functionality should be similar to a LIFO stack
I figure this would make for an efficient UNDO/REDO system for a fixed data type(Byte's).
I have already implemented something like this before, but didn't include dynamic queue re-allocation. My hopes are that STL has something like this already...?
p.s- I hope I made sense... 
[edit]Thinking in C++ says that rings don't exist in STL, so it's safe to assume i'll porlly have to do this myself???[/edit]
Thanx!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
So you basically want a contiguous byte buffer that can be resized where new blocks bytes get added and removed from the end?
Well, you could use vector. Overkill IMHO. Just resize your allocated undo buffer on the fly. Since the buffer might move in memory, you can't store pointers to objects in the buffer. But you can still reference objects in the buffer by their offset from the start.
Also, don't bother with new/delete. Use malloc/realloc/free (OMG, THEY AREN'T TYPE SAFE, I THINK I AM GOING TO CRY). Then you don't have to worry about creating a new buffer, copying it and the freeing the old. Realloc will take care of that for you.
Sure, it isn't "PC", but screw them. You job is to produce software that works. Not "PC" software that works.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote:
Also, don't bother with new/delete. Use malloc/realloc/free (OMG, THEY AREN'T TYPE SAFE, I THINK I AM GOING TO CRY). Then you don't have to worry about creating a new buffer, copying it and the freeing the old. Realloc will take care of that for you.
I think I will actually...not only is it faster, but so much easier to implement...
Thanx
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I am trying to get the internal representation of a double in binary... I am attempting this with a union... could any one show me an example of how this can be done... Please no CString methods, I need to do this myself... any leads would be great.
"Best file compression around: DEL *.* = 100% compression."
<><><><><><><><><><><><><>
Matthew R. Miller
mattrmiller@computersmarts.net
www.computersmarts.net
|
|
|
|
|
What about
double var = 1.2;
PBYTE bin=(PBYTE)&var;
for(int i =0; i < 7;i++) {
cout << bin[i] << endl;
}
|
|
|
|
|
what do you mean by "inbternal representation" ?
if you just want the BYTEs, you can do this:
BYTE *p = (BYTE *)&myDouble;
for (int i=0;i < sizeof(double); i++)
TRACE("%c\n", p[i]);
-c
“If it turns out that I’m actually the one who did it, then looking for the real killers would be a big old waste of time.”
-- OJ Simpson
|
|
|
|
|
I have a FrameWnd where I am splitting the the client horizontally. On the right hand side I would like to split it vertically (similar to outlook). The right hand side is a class called CCourseView. When CCourseView::Create is called I try to create another splitter for within that class. Unfortunately I get an error stating "Failed to create an empty document".
<br />
BOOL CCourseView::Create(LPCTSTR lpszClassName, LPCTSTR lpszWindowName, DWORD dwStyle, const RECT& rect, CWnd* pParentWnd, UINT nID, CCreateContext* pContext) <br />
{<br />
if (!m_wndSplitter.CreateStatic(this, 2, 1))<br />
{<br />
TRACE0("Failed to create splitter window\n");<br />
return FALSE;<br />
}<br />
<br />
if (!m_wndSplitter.CreateView(0, 0, RUNTIME_CLASS(CHoleView),<br />
CSize(0, 90), pContext))<br />
{<br />
TRACE0("Failed to create COutlookPanel\n"); <br />
return FALSE;<br />
} <br />
<br />
if (!m_wndSplitter.CreateView(1, 0, RUNTIME_CLASS(CHoleStatsView),<br />
CSize(0, 150), pContext))<br />
{<br />
TRACE0("Failed to create CCourseView\n"); <br />
return FALSE;<br />
} <br />
<br />
return CWnd::Create(lpszClassName, lpszWindowName, dwStyle, rect, pParentWnd, nID, pContext);<br />
}<br />
Any Ideas?
Sincerly,
Clint Singer
|
|
|
|
|
I do all splitting in my CMDIChildWnd (for you it would be your CFrameWnd) derivative and only after I have successfully CreateStaticed all of my splitters I begin creating the views, all in my overridden OnCreateClient().
This way it works for me.
|
|
|
|
|
Hi.
I implemented a CFormView. I would like to know how do you set the minimum size of the window?
For example, I override OnSize() and add a breakpoint to see if Windows calls that function as I resize the frame. Windows does call OnSize. However, I cannot find a way to limit resize to above a certain size. Right now, the user can resize the frame anyway imaginable include minimizing it to the point where all there is left is the caption bar.
Thanks,
Kuphryn
|
|
|
|
|
Follow these two steps:- In the
OnInitialUpdate of your view, add this by the end of the method:
GetParentFrame()->RecalcLayout();
ResizeParentToFit(FALSE);
- Set the syle of your
CFrameWnd-derived window to non-resizable (play with border styles till you get it) and override PreCreateWindow like this:
BOOL CYourMainFrame::PreCreateWindow(CREATESTRUCT& cs)
{
cs.style&=~WS_SIZEBOX&~WS_MAXIMIZEBOX;
return CFrameWnd::PreCreateWindow(cs);
}
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
i have another question.
i develop my application in the 1024*768,the formview has not scrollbar.
when i change to 640*480 or 800*600, the scrollbar show.
would you like tell me any good method?
|
|
|
|
|
Check out WM_GETMINMAXINFO
Shog9
------
So they took me down to the gallows
And this boy, he said to me:
"Why do you smile, when the rope's around your neck?"
I said, "I tell you boy, when i get back..."
|
|
|
|
|
Okay. Everyone.
Do you add a handler in the mainframe class or the formview class (primary view)?
Kuphryn
|
|
|
|
|
Neither. Your view is contained within a MDI child window (MFC: CMDIChildWnd or derived); this window is the one that the user interacts with to resize, the one that displays the border and caption, and the one you need to add the handler to. If you've been using just CMDIChildWnd, you'll need to create a derived class and use that instead.
Shog9
------
So they took me down to the gallows
And this boy, he said to me:
"Why do you smile, when the rope's around your neck?"
I said, "I tell you boy, when i get back..."
|
|
|
|
|
Okay. Thanks.
I got it to work.
It is interesting that inside the WM_GETMINMAXINFO handler, we have to set the minimux x and y each time. In other words, if the user moves the border 100 pixels, then Windows calls WM_GETMINMAXINFO 100 times and have to set the minimux x and y 100 times. I wonder if there is a more elegant solution as in classing a function that will set the minimum x and y once.
Kuphryn
|
|
|
|
|
kuphryn wrote:
I wonder if there is a more elegant solution as in classing a function that will set the minimum x and y once.
Elegant != Win32, sadly.
Keep in mind, a lot of this originated back when memory was very precious, and windows were resized with those little rubberband-like things, so it probably made sense. Definately avoid heavy-duty calculations in the routine!
Shog9
------
So they took me down to the gallows
And this boy, he said to me:
"Why do you smile, when the rope's around your neck?"
I said, "I tell you boy, when i get back..."
|
|
|
|
|
Advice noted.
Another member mentioned OnSize() inside of the main frame. I do not see any advantage from OnSize() either size it is also called as the user resizes the Window via border.
Kuphryn
|
|
|
|
|
kuphryn wrote:
I do not see any advantage from OnSize() either size it is also called as the user resizes the Window via border.
Exactly. You could use OnSize(), OnSizing(), or OnGetMinMaxInfo() for this, but since the same thing has to be done no matter what it just makes sense to go with OnGetMinMaxInfo() and let Windows do the involved bits for you.
Shog9
------
So they took me down to the gallows
And this boy, he said to me:
"Why do you smile, when the rope's around your neck?"
I said, "I tell you boy, when i get back..."
|
|
|
|
|
kuphryn wrote:
if the user moves the border 100 pixels, then Windows calls WM_GETMINMAXINFO 100 times and have to set the minimux x and y 100 times
That is an artifact of the Window Full Drag feature of windows (When it updates the window while you are resizing or moving it). If this feature is off, you will get a WM_GETMINMAXINFO once so that windows knows where to create the boundaries to resize the window, then when the user lets go and finalizes the resize you will get a WM_WINDOWPOSCHANGING message which its default processor will generate one WM_GETMINMAXINFO, and finally after all of the sizing is done you will get a WM_WINDOWPOSCHANGED, which its default processor will generate another WM_GETMINMAXINFO message.
When the user has Full dragging selected, windows continually finalizes the sizing loop that is generated, in order to force a WM_NCPAINT and WM_PAINT messages to update the window. If the window finalizes this loop 100 times, you will actually get 200 WM_GETMINMAXINFO messages.
Each message has its purpose. When I spent some time looking at the messages that get generated behind the scenes, I was amazed at the sheer number of messages that were generated just to resize a window, or move the mouse.
Resetting the X and Y values each time the message is handled is the proper way to do it. If you do not do it, then windows will in the DefWindowProc. The best way to handle this message is to just have a set of cached values that you use when you want to change these values from the default.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Okay. Thanks.
One final question. I got everything working correctly in OnSize(). As I resize the main frame and move objects according, sometimes the object gets out of scope and disappear. It is really weird. here is a quick example.
[ button ]
// Using MoveWindow()
// Resize main frame and move button to the right to keep it at the center.
[ but ]
It is like even though main frame expands, it does not consider the added area part of it.
What is the best solution?
Kuphryn
|
|
|
|
|
Okay. I figured out the problem. The problem was a logic and programming error, not MFC's fault.
Thanks everyone.
Kuphry
|
|
|
|
|
After getting the IHTMLCollection, and doing get_all etc,
and modifiying the element, the changes to the IHTMLTable
don't appear on the CHtmlEditView.
Any ideas?
<br />
IDispatch... GetHtmlDocument();<br />
...QueryInterface on IHTMLDocument2<br />
pDoc->get_all(&pCollect); <br />
pCollect->item(varID,varIdx, &pDocDisp );<br />
pDocDisp->QueryInterface(IID_IHTMLTable, (void**) &pElem);<br />
<br />
pElem->put_cols(cols);<br />
Thanks
Art
|
|
|
|
|
doing a invalidate(), updatewindow() could help.
or if you wanna save it, get_all again, and save it to the file and refresh it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
