C / C++ / MFC

Re: VS 2010 MFC derived CListbox with dynamically addedCtoolbar

10-Feb-12 5:35

Yes - Overriding PostNcDestroy did it Blush | :O

. In my traces exception also ended up at that point.
Just wasn't comfortable stomping on it like that. Still Kinda curious what I'm doing wrong though -- can't find anything.
I've tried exiting the moment I enter OnInitialDialog -- still throws the @#$%! Heap exception!
So I'm guessing the heap is still corrupted on exit -HoHum

Putting the Create at the end of the OnInitialDialog doesn't matter here - I ended Up creating one function In LBA that registered the LBA class(First time through)then created the LBA frame (which triggered the LBA::OnCreate for the toolbar and Listbox)...
So Making all the creation code in the LBA class -- cuts down on coding to use the class
And used that function in OnInitialDialog (almost at the start)

LBA m_movieframe in Mydialog.h

m_movieframe.UpgradeLB_LBA(CWnd *ptr to static placeholder,&m_movieframe,CWnd *ptr dialog)

passed ptr parent as at the called point as LBA *Cwnd didn't exist (so hard to get to the parent)
This function grabs the static's rectangle ,destroys the static ,reassigns the CtrlId to the frames listbox (Important for trapping LBSelChanged messages ... via the dialogs messagemap.) gotta have a hard CtrlId target

I'm using 6 of this LBA Class in my Dialog
Now --Just to get the trap the messages toolbar, listbox messages to handlers (Duck Soup)

Richard MacCutchan5-Feb-12 23:17

Re: VS 2010 MFC derived CListbox with dynamically addedCtoolbar

5-Feb-12 23:17

You cannot add a toolbar to a child window, only to a frame, so you should add the menu to your dialog resource.

Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman

Fallen1235-Feb-12 23:38

Re: VS 2010 MFC derived CListbox with dynamically addedCtoolbar

5-Feb-12 23:38

Yes - I gathered that I could only add it to the dialog. Done that
But then I'd like to redirect Messages from the parent(Dialog) to the child that created it. Tried subclassing but kept getting assert errors in CWnd::Attach that the window isn't null

C++

	if(m_tools.GetSafeHwnd()!=NULL)m_tools.DestroyWindow();
		if(!m_tools.CreateEx(this->GetParent(),TBSTYLE_FLAT,WS_CHILD|WS_VISIBLE))
			MessageBox(_T("Failed to create toolbar\n"));
		if(-1==m_tools.LoadToolBar(IDR_TOOLBAR1))
			MessageBox(_T("Bitmap not loaded"));
	
		if(!m_tools.ShowWindow(SW_SHOW))
			MessageBox(_T("NoShow"));
		m_tools.ModifyStyle(NULL,CBRS_FLOATING | CBRS_TOOLTIPS | CBRS_FLYBY);
		if(!m_tools.IsWindowVisible())
			MessageBox(_T("Invisible"));
		//and move the toolbar to just above the top of the listbox on the parent CDialog
		this->GetWindowRect(&rec);
		rec.top-=100;rec.bottom=rec.top+16;rec.left-=100;rec.right-=100;
		m_tools.MoveWindow(&rec);
//		if(!SubclassDlgItem(m_tools.GetDlgCtrlID(),this->GetParent()))
//		MessageBox(_T("Failed to Link"));

modified 6-Feb-12 6:44am.

Richard MacCutchan6-Feb-12 0:04

Re: VS 2010 MFC derived CListbox with dynamically addedCtoolbar

6-Feb-12 0:04

I'm not sure what you are trying to do here. What are you subclassing and why? You have a toolbar, so, as you click a button your dialog will receive a WM_COMMAND message, which you can then pass to the appropriate handler.

BTW please format your code a bit and put it inside a code block (via the code button above or with <pre> tags) so it's readable, like this:

C++

if (m_tools.GetSafeHwnd()!= NULL)
    m_tools.DestroyWindow();
if (!m_tools.CreateEx(this->GetParent(), TBSTYLE_FLAT | CBRS_FLOATING | CBRS_TOOLTIPS | CBRS_FLYBY))
    MessageBox(_T("Failed to create toolbar\n"));
// ...

Much more readable.

Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman

Fallen1236-Feb-12 0:35

Re: VS 2010 MFC derived CListbox with dynamically addedCtoolbar

6-Feb-12 0:35

Exactly -- The dialog recieves the message. This involves coding a handler in Dialog class Seems Very very sloppy -- Much more elegant to have the parent redirect the WM_COMMANDS to the child.
My understanding is that subclassing does this. If I can get by the Assert errors

Richard MacCutchan6-Feb-12 1:14

Re: VS 2010 MFC derived CListbox with dynamically addedCtoolbar

6-Feb-12 1:14

Fallen123 wrote:
My understanding is that subclassing does this.

It's a while since I did any subclassing, and even longer for MFC, so I cannot say for sure. The Dialog receives the WM_COMMAND from the toolbar and should then either perform some action or call a function on the child class to perform the action; this may include passing the message direct to the child. I think this article[^] may be of some use in figuring out how it is designed to work.

Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman

Fallen1236-Feb-12 2:16

Re: VS 2010 MFC derived CListbox with dynamically addedCtoolbar

6-Feb-12 2:16

Okay article that fried me.

I was almost sure I couldn't pull this trick (and still thinking about it Trapping OnChildNotify ...).

I think I'll try to derive A Ctoolbar class with a wndproc handler - OnChildNotify firing messages on to my derived clistbox wndproc. It seems that might do it. All it would need is the original Window creating the toolbar.

If that fails

I'll probably just recreate my class Via CFrame, add the cListbox and toolbar. write the toolbar handler in Cframe ... and make the CFrame invisible using Defines

Still it seems that you should be able to rout the WndProc messages of a child to any handler you want. Then filter, and send unprocessed messages to the original handler.

One way or the other Thanx for your input

Richard MacCutchan6-Feb-12 3:03

Re: VS 2010 MFC derived CListbox with dynamically addedCtoolbar

6-Feb-12 3:03

Fallen123 wrote:
I think I'll try ...

I'll probably ...

I think you are just making more work and complications for yourself. I'm still not sure what you are trying to achieve, but handling command messages and using them to perform actions in child windows is basic stuff that all Windows applications perform by following the standard rules. You seem to be trying to create your own system that is outside of the Microsoft design, and are getting tied in knots trying to solve a problem that doesn't exist.

Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman

Fallen1236-Feb-12 6:35

6-Feb-12 6:35

Well it worked - Damn so simple

Now I can dynamically create/link any control without resorting to a frame class
directly to another - transparent to the Main dialog -- very useful

Derived a class from CToolbar toolbaradv
passed it the CWnd * pointer to ListboxAdv window -- m_Creator

Added handler

C++

void toolBarAdv::OnNMClick(NMHDR *pNMHDR, LRESULT *pResult)
{
	LPNMCLICK pNMClick = reinterpret_cast<LPNMCLICK>(pNMHDR);
	m_Creator->SendMessage(10001,GetToolBarCtrl().GetHotItem());
	*pResult = 0;
}

And caught the message in Derived listbox WndProc

All without having to touch the main parents message loop
And No "getting tied in knots trying to solve a problem that doesn't exist."
The problem has always been MS arrogance that "They have covered all the bases"
and not left room for expansion

A Class (or derived class) should be able to handle its messages pertaining to that class -- An options bar certainly qualifies -- you don't handle options local to the class externally --thats just bad widget design

This all got started because MS CListbox Doesn't allow access to resize its working area for the list

Example. A clistbox (no integral height),you add items and suddenly a scrollbar appears
(So a child scrollbar was Dynamically added and the listbox internals were recalculated to accomodate it --A variant of what I'm trying to do - Add a needed child) -- but try to find/modify the bloody routines that recalculate.
Basically I'm doing the same thing - Simply add a toolbar pertaining to options for the new derived listbox --Though not actually "in" but on in this case

PS in my dialogs I have 10 of these Listboxes -- think of the handling in main dialog message loop

Well nap time

SegFault

chidacode5-Feb-12 7:07

chidacode

5-Feb-12 7:07

I have a stack. When compiled with O3 it crashes. Works fine when compiled with -g . Any idea what is issue n how to debug it.

modified 5-Feb-12 13:35pm.

Albert Holguin5-Feb-12 8:45

5-Feb-12 8:45

What are you talking about? compiler options, linker options? Clarify your question, it's not clear.

CPallini5-Feb-12 21:57

CPallini

5-Feb-12 21:57

Compiler does ~~ugly~~ nice tricks when optimization is ON (on the other hand the debug build may hide some errors - e.g. it may initialize data you forgot to).
However we cannot help you more, without seeing your code.

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

Albert Holguin6-Feb-12 10:14

6-Feb-12 10:14

CPallini wrote:
it may initialize data you forgot to

I hate it when it does that... Thumbs Down | :thumbsdown:

Stephen Hewitt6-Feb-12 4:07

Stephen Hewitt

6-Feb-12 4:07

Not unusual. The bare minimum you should provide is a call stack and the source code around the actual code that blows up (if possible).

Steve

TCP/IP problems

ForNow4-Feb-12 16:27

ForNow

4-Feb-12 16:27

Hi,

I don't know if i am in the right forum as my problem seems to be unserstanding of TCP/IP as opposed to MFC

I am using CAsynSocket class to communicate with a server running on a MainFrame

I have my CAsyncSocket object wrapped inside a CWinThread object

In the CWinthread::Initinstance I do CAsyncScoket::Create get a 1 return code to

indicate success

On the MainFrame end I have a Select command looking for connections from the client

Stepping thru the code on Visual Studio after the CAsynSocket::connect I get

a 0 return code the Getsystem error is 10035 (connection not complete)

The (Server) however on the mainFrame detects a connection and issues a subsequent

Accept then is waitting to read information from Windows MFC client

My problem is that the Windows MFC Client CASyncsocket::OnConnect callback function is

never invoked to complete the connection from the client

Any help of someone pointing me to where I can further debug this would be appreciated

Thanks

Mohibur Rashid5-Feb-12 4:34

Mohibur Rashid

5-Feb-12 4:34

The thing I want to point out(just a guess) is that may be because of debugging process your connection is getting lost in the middle. You should check. Try to skip few parts during debugging and check if it returns the proper value

Albert Holguin5-Feb-12 8:42

5-Feb-12 8:42

On the client side... why don't you try using a synchronous socket first? The biggest difference is that all the calls will block until they return but the coding should be simpler... and the asynch and synch sockets are essentially the same internally (within the framework). If the synchronous socket doesn't work, maybe you're doing something else wrong, hard to tell without any code. There could be a number of things wrong.

ForNow5-Feb-12 12:14

ForNow

5-Feb-12 12:14

Hi,

I am assuming you are refering to CSocket class since it is derived from CAsynSocket

I can call CSocket::connect

it will block unitil connection is complete

Albert Holguin5-Feb-12 13:46

5-Feb-12 13:46

Yeah, that's the difference between the two, one is synchronous and the other is asynchronous.