|
How do i open an Dialog BOx from the SDI Main Frame Menu. I tried to use Do.Modal()with the Dialog class object , but it caused an assetion. If i ignore the assertion, it runs perfectly fine. I want to get rid of that assertion.
|
|
|
|
|
What causes the assertion? SDI menu has nothing to do with a dialog box. I suspect that the dialog box is not initialized correctly.
Kuphryn
|
|
|
|
|
I created an object of my Dialog class called Window.In order to open the dialog class i did Window.DoModal();
That is when assertion came up.
|
|
|
|
|
|
assertion says
Debug Assertion failed.
File:afxwin2.inl
Line 162.
i think it is due to some inappropraite use of function DoModal().
|
|
|
|
|
Can you post the code that you are using to create the dialog box as well please... it might make it a bit easier to see what is going on.
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
It could be that your dialog contains a CWnd derived member that's not linked to a control. But it's impossible to say for sure unless you post some code.
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
here is the Function that is used to create the dialog box when a SDI menu item is clicked.That menu item is called Jaguar.
Jagwindow is my object for class CJaguarDlg.
Hope this clarifies things.
void CVR_ToolView::OnJaguar()
{
CJaguarDlg JagWindow;
int nRet=JagWindow.DoModal();
}
|
|
|
|
|
Sadly, that's of no help. How about posting the OnInitDialog() of CJaguarDlg . Also post its .h file.
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
ppathan wrote:
i think it is due to some inappropraite use of function DoModal().
No. Somewhere in your dialog or in one of the embedded controls, a RedrawWindow() is being called before the dialog is created properly, possibly in OnSize() or something like that. If you've put this in, then do this:
if(::IsWindow(m_hWnd))
RedrawWindow(); Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
i want to know more info about CEditView.
Thanks very much!
|
|
|
|
|
MSDN has a plethora of information, examples too! You might even find some examples right here at CP!
|
|
|
|
|
I am working on a text editor (uses richedit, MFC, SDI) that on right mouse click, in certain situations, will spawn a control for a value to be input. An edit box, or list control, for example. I was developing the software on Windows 98 (bah), and it was working fine, but when I tested on XP, I hit a wall.
The thing is, the controls are supposed to dissapear once they lose focus (setting a value). Initially, the controls were losing focus instantly after creation, which was driving me insane - I dont know the cause still. So I rewrote the code to act not when focus is lost, but when the user clicks on the rich edit view (out of the control). It fixed the instant close problem, but I have found now that the controls seem to act as if they are not there. The cursor does not change when it goes over the control, and clicking on the control is as if clicking on the view outside of the control.
I assume XP has a different way of handling the rich edit system or something like that. Should I just recompile on XP, or what?
Here is my control creation process:
1) Create an instance
2) Call create (WS_CHILD | WS_TABSTOP | WS_BORDER are my common styles)
3) Set the data (list selections, edit box initial text, etc)
4) Set the font
5) Reposition with SetWindowPos, setting the control topmost in Z order, showing the control, and moving+sizing the control
6) Set focus on the control
It is a bit dragged out like that because the manor in which it is handled (3 different control types are handled by the same creation routines).
Any ideas? Thanks.
|
|
|
|
|
I'm currently using controlbars (stingray studio SECControlbars which are derived from CControlbar) and I'm trying to limit the size that you can reduce them to. Currently, i'm able to catch the WM_SIZE message in my SECControlbar derived class, but im not entirely able to control the actual sizing. What happens is i catch the size message and im able to see what size is requested, but when i attempt to change the size and pass to the base class, the results are incorrect.
In my specific case, im trying to limit the width of a vertical controlbar to 132 or more pixels. What happens with my code is the first sizing that goes below the 132 barrier actually happens despite my efforts to stop it. When i size again (also attempting below 132) the size is adjusted towards my 132 barrier but not exactly right and depending on how small i actually tried to make it. These two results happen one after the other, so every other size appears to try and size correctly. I think im setting my size after the actual controlbar size is interpretted but i can't seem to find the message i should capture and override to prevent this. I've tried using spy++ on the window but i can't seem to find any other messages that could be responsible. I also think I could be misusing the CalcDynamicLayout() function, but i've tried most all of the options and it doesnt seem to matter all that much. Any solution for a CControlbar should work in this situation, but i haven't seen one in any examples.
Here's part of my OnSize handler:
void VHelpDlg::OnSize(UINT nType, int cx, int cy) <br />
{<br />
<br />
VMainFrame *pMainFrame = static_cast<VMainFrame*>(AfxGetMainWnd());<br />
if(pMainFrame)<br />
VGENyDoc* pDoc = pMainFrame->GetDocument();<br />
else<br />
return;<br />
<br />
CSize szCtrlBar;<br />
<br />
if(this->m_szDockVert.cx<132)<br />
{<br />
this->m_szDockVert.cx=132;<br />
cx=132;<br />
szCtrlBar=CalcDynamicLayout(132,LM_COMMIT|LM_VERTDOCK|LM_STRETCH); <br />
}<br />
SECControlBar::OnSize(nType,cx,cy); <br />
Invalidate();<br />
}<br />
Jeff Rothenberg
Project Engineer
Vector CANtech, Inc.
|
|
|
|
|
Straight from the documentation:
The framework calls this member function after the window’s size has changed. The parameters passed to your function reflect the parameters received by the framework when the message was received. If you call the base-class implementation of this function, that implementation will use the parameters originally passed with the message and not the parameters you supply to the function.
You need to look at CWnd::OnGetMinMaxInfo().
|
|
|
|
|
I put a handler for WM_GETMINMAXINFO in as OnGetMinMaxInfo() but sizing the control bar never results in the program entering this code. I'm not sure if this control bar acts like a standard CWnd, the WM_SIZING message never gets called either. Perhaps this message is being handled for me at a lower level class?
Jeff Rothenberg
Project Engineer
Vector CANtech, Inc.
|
|
|
|
|
Hi Everybody,
I've spend some time trying to attach a dialog to winamp 2.xx(like the Plugins for winamp). It's not a Plugindll, but an indipendent exefile. I've tried to do it with;
HWND m_hWinamp = FindWindow("Winamp v1.x",NULL); //Find Winamp
CWnd pWin;pWin.m_hWnd = m_hWinamp; //(Is this possible?) I've tried to generate a CWnd for the Createfunction
//this code is for making the modeless Dialog
CTestDlg *dlg = new CTestDlg;
dlg->Create(IDD_TEST_DIALOG, &pWin);
dlg->ShowWindow(SW_SHOWNORMAL);
But i get an abnormal program termination in the dlg->Create(IDD_xyz, &pWin) line as i run the program. Is it after all possible to attach my own window to an other program, or is there another, better way to something like that?
Thanks for your help! I hope i've explained it clearly
|
|
|
|
|
I dont think you can have a parent window that lives in another exe. And you should use CWnd::Attach if you want to connect a HWND to a CWnd. But I dont think it will work as its in another memory space.
So write a Plugin or inject your own dll into the winamp EXE.
Magnus
|
|
|
|
|
Ok, i've made a dll out of it, and it works as far as i had come good. But now i want to catch some keypresses. I've made it with PreTranslateMessage in the orig. program. But in the dll no messages came through. Nor Mouse, size, key or whatever events...what did i do wrong`?
|
|
|
|
|
When does an entry get written to the registry for the Recent File List? My application is no longer writting these entries and I can't figure out where it's suppose to occur.
|
|
|
|
|
Have you looked into CWinApp::SaveStdProfileSettings()?
|
|
|
|
|
I looked there but I didn't bother to put a breakpoint to see if it was getting there. I had overridden the CWinApp->ExitInstance(). I made a call to the SaveStdProfileSettings() there and everything is back to normal.
Thanks David,
Rome
|
|
|
|
|
I lost those file: StockData.cpp, StockData.h, StockDataList.cpp and StockDataList.h
Everyone has, please send me?
Thanks
|
|
|
|
|
I have been trying all day to get a file open dialog box that would not give me any errors. I have tried the CFileDialog Box which looked like this:
CFileDialog *fileDlg = new CFileDialog(TRUE, "*.exe", NULL, OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST, "Executable files (*.exe)|*.exe||", GetActiveWindow());
// Initializes m_ofn structure
fileDlg->m_ofn.lpstrTitle = "Half-Life Executable Path";
// Call DoModal
if ( fileDlg->DoModal() == IDOK)
{
m_PATH.SetWindowText(fileDlg->GetPathName());
}
delete fileDlg;
I have also tried the windows api way (non mfc) (this is for a dll, i think i have to change the return type too):
char *Open_File(HWND m_hwnd)
{
OPENFILENAME ofn;
char szFileName[MAX_PATH];
ZeroMemory(&ofn, sizeof(ofn));
szFileName[0] = 0;
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = m_hwnd; //handle to your window
ofn.lpstrFilter = "Half-Life Executable (*.exe)\0*.exe\0\0";
ofn.lpstrFile = szFileName;
ofn.nMaxFile = MAX_PATH;
ofn.lpstrDefExt = "exe";
ofn.Flags = OFN_EXPLORER | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;
if(GetOpenFileName(&ofn))
return ofn.lpstrFile;
else
return "";
}
If I open the file dialog box and then click ok after selecting a file it will do this fine in the window:
m_PATH.SetWindowText(fileDlg->GetPathName());
I have a main window and an options screen. The options screen is in a modal state when I call the file dialog and the parent of the file dialog is the options screen. Now up to this stage it is all dandy because I can close the options screen then open the options screen again and it will display the previously selected file because I save it and load it into the text control. But when I close the program I get this:
he thread 0xF14 has exited with code 133 (0x85).
The thread 0xB88 has exited with code 133 (0x85).
The thread 0x4CC has exited with code 133 (0x85).
The thread 0x5B8 has exited with code 133 (0x85).
The program 'C:\Console Connector++\HLCC 0.5a\Debug\HLCC.exe' has exited with code 133 (0x85).
I ended up playing with it all and found out I only get this when I call GetOpenFileName. After using the file dialog I can no longer do file output. By the way im using VC++ 6.0 SP5.
Argghhhh!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! It is very urgent cause Im doing an update for my program that people use!!!
Thanks.
|
|
|
|
|
I'm not sure what your problem is. Are you concerned about all those spurious threads? If so, do not worry about them, they're internally launched by the system when you call GetOpenFileName , it's nothing to care about.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|