C / C++ / MFC

19-Sep-01 6:10

Hi, I have a Home-Made control who post a message. This control can be placed anywhere. All of this stuff run very well but something is not like I wan't it to be and it's the first time I use Message queuing

void MyHomeMadeControl::AMethod(void)
{
    
    PostMessage(GetParent(),
                (UINT)this,
                (long)&m_Var);

}

class CBoopView : public CView
{
//some stuff
MyHomeMadeControl m_Ctrl_1;
MyHomeMadeControl m_Ctrl_2;

//everything else
}

void CBoopView::OnZoomScroll(MyHomeMadeControl* WParam,MyHomeMadeParam* lParam)
{
    if(&m_Ctrl_1 == WParam)
    {
        //Here I know it's m_Ctrl_1
    }
    else
    {
        //Here m_Ctrl_2...
    }
}

I don't think it's a very good way to do so...
It is possible in my PostMessage to do something like

PostMessage(GetParent(),
            GetCurrentId(), //this return the Id of my CWnd (you know the UINT nID of the create function)
            (long)&m_Var);

so that way I will used Id number instead of pointers...

thanks

(by the way if there is a "standart way to identify the Object who Post the message tell me)

Remi Morin
Rmorin@Operamail.com
Remi.Morin@Lyrtech.com

Tomasz Sowinski19-Sep-01 7:05

19-Sep-01 7:05

Wrong, wrong, wrong. You're trying to use a parent window pointer as message identifier. This will not work.

#define WM_MY_MESSAGE (WM_USER + 1)
...
GetParent()->PostMessage(WM_MY_MESSAGE, someWparam, someLparam);

You can pass object pointer as wParam or lParam, as long as window that's going to process the message is in the same process. In your case it's true. There's another caveat: PostMessage places message in the queue. Receiving window will not get this message immediately - and depending on application, the object that you passed as message parameter may no longer exist. In such case, use SendMessage instead of PostMessage.

One final note: when you are using your controls only within this program, you may establish communication between windows without messages. Just cast the pointer returned by GetParent() to correct type and call whatever method you need:

// inside YourHomeMadeControl
CBoopView *pView = (CBoopView*)GetParent();
pView->Foo(param1, param2, param3);

Tomasz Sowinski -- http://www.shooltz.com

Remi Morin19-Sep-01 7:44

19-Sep-01 7:44

Some difficulties to understand...
this is a sumary of my .h file

class MyHomeMadeControl :public CWnd
{
// Construction
public:
   MyHomeMadeControl ();
// Overrides
   // ClassWizard generated virtual function overrides
   //{{AFX_VIRTUAL(MyHomeMadeControl )
	private:
   virtual BOOL Create(const RECT& rect, CWnd* pParentWnd, UINT nID, CCreateContext* pContext = NULL);
	//}}AFX_VIRTUAL

// Implementation
public:
   virtual  ~MyHomeMadeControl ();
 // Generated message map functions
protected:
   //{{AFX_MSG(MyHomeMadeControl )
   afx_msg  void OnPaint();
   afx_msg void OnTimer(UINT nIDEvent);
   //}}AFX_MSG
   DECLARE_MESSAGE_MAP()
};
static UINT WM_ON_TIMER_HOMEMADE= RegisterWindowMessage("MyHomeMadeControl_OnTimer");

and then the function on timer in the cpp file:

void CGraphScroll::OnTimer(UINT nIDEvent)
{
//here to ba able to import this code anywhere I have to do something like this
GetParent()->PostMessage(WM_ON_TIMER_HOMEMADE,(UINT)this,something);

/*this will require a #include "parent.h" witch I don't know
((CBoopView)GetParent())->OnTimer(Anything I want)
*/
}

So in a boopView (who can be a any kind of CWnd derived class) I have to trap this message, and I can have 0 to n instance of MyHomeMadeControl.

So for catch the message what I did work, but it's very strange... for a CButton It work very well and it's done like this

ON_BN_CLICKED(IDC_BUTTONX, OnButtonX)

ON_BN_CLICKED is a macro and it will be replace by

ON_CONTROL(BN_CLICKED, IDC_BUTTONX, OnButtonX)

it's exactly what I wan't to re-create with my Home made control, no matter how many of them exist, any of them will find whitch handler to use...

ON_CONTROL(WM_ON_TIMER_HOMEMADE,IDC_MYHOME_MADE_CONTROL_1,OnTimerControl_1)
ON_CONTROL(WM_ON_TIMER_HOMEMADE,IDC_MYHOME_MADE_CONTROL_2,OnTimerControl_2)

this doesn't work...

Remi Morin
Rmorin@Operamail.com
Remi.Morin@Lyrtech.com

Tomasz Sowinski19-Sep-01 8:09

19-Sep-01 8:09

So your control is designed to be a child of any parent and you want to use ON_CONTROL? It's easy: just remember that you need to call SendMessage rather than PostMessage (there's no need to use a queue). Control notifies its parent by sending one of two messages: WM_COMMAND or WM_NOTIFY.

In 16-bit Windows there was only WM_COMMAND, that's why edit, listbox, button and other 'old' controls use this method. OTOH, common controls that made their debut in 32-bit Windows, like listview, treeview, toolbar etc. use WM_NOTIFY. I'd suggest to use WM_NOTIFY as a method of communitaction between the control and any parent window. Use the following code to notify the parent about some event. Note the NM_SOMEEVENT - this is just a unsigned integer number that your parent needs to know. There's no need to use RegisterMessage in this scenario.

NMHDR hdr = { m_hWnd, ::GetWindowLong(m_hWnd, GWL_ID), NM_SOMEEVENT };
GetParent()->SendMessage(WM_NOTIFY, hdr.idFrom, (LPARAM)&hdr);

Parent will get WM_NOTIFY. MFC magic routes this message through message map. Use ON_NOTIFY to insert the handler into msgmap of parent window:

ON_NOTIFY(NM_SOMEEVENT, IDC_MYHOME_MADE_CONTROL_1, OnSomeEvent)

More details in MSDN, just search for WM_NOTIFY and ON_NOTIFY.

Tomasz Sowinski -- http://www.shooltz.com

Remi Morin19-Sep-01 9:02

19-Sep-01 9:02

thanks, it work very well Smile | :)

So it's the way to do that
but question, this structure take all my parameters so in my method (OnSomeEvent in you'r example) I have to call a method like

m_cMyHomeMadeControl.GetCurrentValues(all parameters I wan't)

it's a good way (the parent have to know what is his child)

Remi Morin
Rmorin@Operamail.com
Remi.Morin@Lyrtech.com

Tomasz Sowinski19-Sep-01 9:15

19-Sep-01 9:15

Calling child directly is one possibility. However, you could also easily add your own information. Just derive some struct from NMHDR:

struct MyNotifyInfo : public NMHDR
{
int yourMember1;
char yourMember2[100];
};

You could also create struct with NMHDR as first member:

struct MyNotifyInfo
{
NMHDR nmhdr;
int yourMember1;
char yourMember2[100];
};

The second method is used by Windows SDK - these header files must be compilable even in plain old C which doesn't support inheritance. Have a look at MSDN docs for NMTREEVIEW, NMLISTVIEW or any struct named NMxxxx.

In the parent's handler, just cast NMHDR* to MyNotifyInfo* and you'll be OK.

Tomasz Sowinski -- http://www.shooltz.com

Remi Morin19-Sep-01 9:57

19-Sep-01 9:57

last question...
NMHDR hdr = { m_hWnd, ::GetWindowLong(m_hWnd, GWL_ID), NM_SOMEEVENT };
NM_SOMEEVENT - There's no need to use RegisterMessage in this scenario...

I can use any value?? 0 to maximum unsigned int?
does it can be in conflict whit parent event? or (as I think) only whit MyHomeMadeControl event (in witch case it is easy to avoid)

...

thank you very much for you'r help, it's easy to do code whitout bother whit anything... but take care of everything in a windows program is very hard and good book are not easy to find. Thank you very much

Smile | :)

Remi Morin
Rmorin@Operamail.com
Remi.Morin@Lyrtech.com

Tomasz Sowinski19-Sep-01 10:20

Problem with msadox.dll and msado15.dll

19-Sep-01 10:20

There's no possibility of the conflict. Parent's handler will be called only if both conditions are true:

1) code member of NMHDR is equal to 1st parameter of ON_NOTIFY
2) idFrom member of NMHDR is equal to 2dn parameter of ON_NOTIFY

In fact, you can use any value as code. However, it would be a good practice to avoid range of codes starting with NM_FIRST and NM_LAST. In this range you'll find some general-purpose codes, like NM_CLICK. I think you should use NM_LAST+1, NM_LAST+2 etc. for your notification codes.

Tomasz Sowinski -- http://www.shooltz.com

19-Sep-01 5:27

I have a problem and I don't know what to do !!!! I'm trying to learn but the compiler don't help me !!!!

My code:

#import "msado15.dll" no_namespace rename( "EOF", "adoEOF" )
#import "msadox.dll"

And I get:
msadox.tlh(98) : error C2011: '_Collection' : 'struct' type redefinition
(... Thousands of sentences like the one above ...)

What am I doing wrong ??? Why is redefiniting everything if they're different libraries ??? What sould I do ????

Re: Problem with msadox.dll and msado15.dll

Remi Morin19-Sep-01 5:53

Problem with msadox.dll and msado15.dll

19-Sep-01 5:53

I don't know, I'm using the same line than you to load msado15.dll but i don't have this problem.

you can try this (maybe you import it more than once

#if !defined __MY_IMPORT_OF_MSADO15_DLL__
#define __MY_IMPORT_OF_MSADO15_DLL__
#import "msado15.dll" no_namespace rename( "EOF", "adoEOF" )
#endif

Remi Morin
Rmorin@Operamail.com
Remi.Morin@Lyrtech.com

19-Sep-01 5:59

No, it's not that !!!!

The problem is that msadox.dll and msado15.dll have some of the same collections defined and this is why they get redefined !!!!! How can I solve it ??????

Re: Problem with msadox.dll and msado15.dll

Carlos Antollini19-Sep-01 5:58

Carlos Antollini

19-Sep-01 5:58

Import the dlls in diferent Files.

Use the ado functions in a file, and the adox functions in other one.

Cheers!!!

Carlos Antollini.

Re: Problem with msadox.dll and msado15.dll

19-Sep-01 6:04

Yes, if I use that everything goes OK, but the problem is that I have two classes (one using msado15.dll and the other using msadox.dll) and I want them to share the connection, so I thought of passing the ConnectionPtr from one class to the other. Otherwise, I've to do two different connections to the same source and It's not very efficient.

I found this in msdn:

// BeginCloseConnectionCpp
#import "c:\Program Files\Common Files\system\ado\msadox.dll" \
no_namespace
#import "c:\Program Files\Common Files\system\ado\msado15.dll"

and in a function:
m_pCatalog->PutActiveConnection(_variant_t((IDispatch *)m_pCnn));

where m_pCnn is a ConnectionPtr

That's what I want to do !!!!!

LoadString...

19-Sep-01 5:05

CString strTest;
strTest.LoadString(IDS_Test); // IDS_Test == "Hello, world!"
cout << strTest << "\n";

output: "0077046C"

this is not exactly what i expected...can somebody help?

Not Active19-Sep-01 6:04

Not Active

19-Sep-01 6:04

This code comes from VC++ Wizard, Console App with MFC support

CString strHello;
strHello.LoadString(IDS_HELLO);
cout << (LPCTSTR)strHello << endl;

19-Sep-01 8:06

ok, and what does (LPCTSTR) in front of "strHello" means?

to convert the string into that type?

Not Active19-Sep-01 9:59

Not Active

19-Sep-01 9:59

It means that you should pick up a book and read.

Steen Krogsgaard19-Sep-01 23:39

Steen Krogsgaard

19-Sep-01 23:39

LOL

)) good one!

Cheers
Steen.

"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"

Carlos Antollini19-Sep-01 10:20

Carlos Antollini

19-Sep-01 10:20

SShhh:
I will say you a secret. Cool | :cool:

LPCTSTR is a 32-bit pointer to a constant character string.

Best regards!!!

Big Grin | :-D

Carlos Antollini.

The_Server19-Sep-01 21:08

The_Server

19-Sep-01 21:08

I think the exect translation is:

L - Long
P - Pointer
C - Const
T - (somthing (could be TCHAR (I don't remember)))
S \
T = - Str
R /

BTW: come to #CodeProject on DalNet (mIRC)

The_Server19-Sep-01 21:09

The_Server

19-Sep-01 21:09

correction:
==========
I think the exect translation is:

L - Long
P - Pointer
C - Char
T - (somthing)
S \
T = - Str
R /

LPCTSTR = const char *
LPCSTR = char *

I think

BTW: come to #CodeProject on DalNet (mIRC)

Steen Krogsgaard19-Sep-01 23:31

Steen Krogsgaard

19-Sep-01 23:31

Nope, the first one was correct: Long Pointer to Const Tchar String

in WinNT.h: (well, this isn't directly transcript, but you'll get the idea)

#ifdef UNICODE
typedef wchar_t WCHAR;
typedef CONST WCHAR *LPCWSTR; // Long Poiner to Const WCHAR String
typedef WCHAR *LPWSTR; // Long Pointer to WCHAR String
typedef WCHAR TCHAR;  // build-type independent char type
typedef LPCWSTR LPCTSTR;  // build-type independent const string type
typdef LPWSTR LPTSTR; // build-type independent non-const string type
#else
typedef char CHAR;
typedef CONST CHAR *LPCSTR; // Long Pointer to Const String
typedef CHAR *LPSTR;
typedef CHAR TCHAR;     // \
typedef LPCSTR LPCTSTR; // = build-type independent strings.
typedef LPSTR LPTSTR;   // /
#endif

not that it really matters in the long run Wink | ;)

Cheers
Steen.

"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"