C / C++ / MFC

Re: Need CEditView source code or Example

8-Jul-03 9:36

i want to know more info about CEditView.
Thanks very much!

David Crow8-Jul-03 9:44

Restricting resizing of controlbars

8-Jul-03 9:44

MSDN has a plethora of information, examples too! You might even find some examples right here at CP!

Controls losing focus

PaulFrazee8-Jul-03 8:31

PaulFrazee

8-Jul-03 8:31

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.

electronicman_x8-Jul-03 8:08

electronicman_x

8-Jul-03 8:08

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.

Re: Restricting resizing of controlbars

David Crow8-Jul-03 9:54

Re: Restricting resizing of controlbars

8-Jul-03 9:54

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().

electronicman_x8-Jul-03 10:36

electronicman_x

8-Jul-03 10:36

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.

Modeless Child Dialog

Daishy8-Jul-03 8:00

Daishy

8-Jul-03 8:00

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 Smile | :)

Re: Modeless Child Dialog

Magnus Westin8-Jul-03 8:14

Magnus Westin

8-Jul-03 8:14

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

Re: Modeless Child Dialog

Daishy10-Jul-03 3:38

Daishy

10-Jul-03 3:38

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`?

Recent File List (MRU)

Rome Singh8-Jul-03 7:26

Rome Singh

8-Jul-03 7:26

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.

Re: Recent File List (MRU)

David Crow8-Jul-03 7:34

Re: Recent File List (MRU)

8-Jul-03 7:34

Have you looked into CWinApp::SaveStdProfileSettings()?

Rome Singh8-Jul-03 7:45

Rome Singh

8-Jul-03 7:45

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

Everyone has STUpload source code in MCSD C++ Kit?

Anonymous8-Jul-03 7:06

GetOpenFileName thread problem

8-Jul-03 7:06

I lost those file: StockData.cpp, StockData.h, StockDataList.cpp and StockDataList.h

Everyone has, please send me?

Thanks

Anonymous8-Jul-03 6:59

8-Jul-03 6:59

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.

Joaquín M López Muñoz8-Jul-03 7:08

Joaquín M López Muñoz

8-Jul-03 7:08

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

John M. Drescher8-Jul-03 7:14

John M. Drescher

8-Jul-03 7:14

Joaquín M López Muñoz wrote:
Are you concerned about all those spurious threads? If so, do not worry about them

I agree. I have several multithreaded programs that I have written and I see this kind of thing all the time during the execution of the program. These threads are internal to windows and there is no reason to worry about them.

John

Anonymous8-Jul-03 7:29

8-Jul-03 7:29

But the thing is after using the file dialog it will NOT let me save any data through file ouput.

David Crow8-Jul-03 7:24

8-Jul-03 7:24

So if you've found that CFileDialog works and GetOpenFileName() doesn't, why are you still trying to use GetOpenFileName()?

While the multiple threads that are being spawned is normal, a non-zero return value is suspect.

Just to rule out a scope problem, change your code to:

OPENFILENAME ofn;
char szFileName[MAX_PATH];
char *Open_File(HWND m_hwnd)
{
    ZeroMemory(&ofn, sizeof(ofn));
    ...
}

I have a hard time using code where functions return auto variables. That whole going-out-of-scope thing can cause hours of grief.

Anonymous8-Jul-03 7:31

8-Jul-03 7:31

CFileDialog has the same results as GetOpenFileName.

David Crow8-Jul-03 7:38