C / C++ / MFC

Re: Passing datas from an editbox in the toolbar to the view.cpp

9-Apr-08 10:21

P.S.:

I also tried this

void CNonButtonCtrlinToolBar1View::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags) 
{
	if (VK_RETURN) 
	{
		MessageBox("test","test",MB_OK); 
	}
	CView::OnChar(nChar, nRepCnt, nFlags);
}

I think that thie code will work but there is still don't know how to notify the view in the right way Confused | :confused:

Thanx for your help
hopefully
croc

CrocodileBuck9-Apr-08 22:47

Re: Passing datas from an editbox in the toolbar to the view.cpp

9-Apr-08 22:47

OK,

OnChar is the wrong way ! Cry | :((

Could anybody help me ??? Confused | :confused:

Thanx for your help
Best regards
Croc

CrocodileBuck10-Apr-08 3:34

Re: Passing datas from an editbox in the toolbar to the view.cpp

10-Apr-08 3:34

Hi,

is my question too stupid, too difficult or have i made mistakes in my posting ?

Thanx for your help
Best regards
Croc

Nelek10-Apr-08 4:49

Nelek

10-Apr-08 4:49

There are another options as different time zones, people works or sleeps and so on. Be patient. Somebody will help you

Greetings.
--------
M.D.V. Wink | ;)

If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

Re: Passing datas from an editbox in the toolbar to the view.cpp

Mark Salsbery10-Apr-08 6:11

Re: Passing datas from an editbox in the toolbar to the view.cpp

10-Apr-08 6:11

Plus if you reply to your own posts, I never get an email notifying me that you posted Smile | :)

You have the enter key event at the edit control class.

Now you need to somehow relay that info to the view.

There's an infinite amount of ways to do that.
The easiest thing to do would be to post a user-defined message to the parent of the edit control's parent.
You could also post the message to the app's main window - depends on your window hierarchy.

Let's say your window hierarchy is like this:

FrameWindow
   ToolBar
      Edit Control
   View

To get a message to the view from the edit control, post the message to the parent of the edit control's parent,
which is the frame window. Add a handler for the message in the framewindow class. In that handler, GetActiveView()
can be used to get the view window to forward the message on to.

That's one example using window messages.

Another alternative is to pass window object pointers down to the edit control at creation time, and
call methods of the window class directly from the edit control class. This solution is much less elegant
because it binds a bunch of window classes together in a way they can't be reused easily...not a good
object-oriented design.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

CrocodileBuck10-Apr-08 23:29

Re: Passing datas from an editbox in the toolbar to the view.cpp

10-Apr-08 23:29

Hi. Mr Salsbery Wink | ;)

,

thanx for your reply , i will try the first option now !

Thank for your help
Best regards Croc

CrocodileBuck11-Apr-08 0:04

Re: Passing datas from an editbox in the toolbar to the view.cpp

11-Apr-08 0:04

Hi Mr. Salsbery,

my new MyEdit.cpp :

BOOL CMyEdit::PreTranslateMessage(MSG* pMsg)
{
	NEW_cLoadFile mlf;
	cTest test;
	
    if (pMsg->message == WM_KEYDOWN && VK_RETURN == pMsg->wParam) 
    {
        return TRUE;
    }
    else if (pMsg->message == WM_KEYUP && VK_RETURN == pMsg->wParam) 
    {

		CView* pView = (((CMainFrame*)AfxGetMainWnd())->GetActiveView());
	 	pView->SendMessage(WM_SETTEXT,0,'test');
		
        return TRUE;
    }
	
    return CEdit::PreTranslateMessage(pMsg);
}

And here is the View.cpp of the project:

.
         .
         .
         .
         .
void CNonButtonCtrlinToolBar1View::OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint) 
{

		CString text;
 		MessageBox(text,text,MB_OK);
		
}

This won't work Frown | :(

Unfortunately i don't know much about the message handling in the mfc Frown | :(

Could yo perhaps correct the code ??? Confused | :confused:

P.S.:i really forgot the time zone D'Oh! | :doh:

Thanx for your help
Best regards
Croc

Mark Salsbery12-Apr-08 5:58

12-Apr-08 5:58

You should probably be sending a user-defined message.

The receiving window will need to have a handler for that user-defined message.

CrocodileBuck wrote:
Unfortunately i don't know much about the message handling in the mfc

It's actually Windows messaging - that's essential knowledge for Windows programming.
I'd definitely recommend studying that and knowing it if you're going to do Windows GUI programming Smile | :)

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

DLL Thread_attach

ForNow9-Apr-08 6:46

9-Apr-08 6:46

Hi,

Was wondering when someone gets the THREAD_ATTACH message (sine my app has lots of threads)

Is there anyway of finding out information/identify about this thread.. Thread Name would be nice

I guess I could do GetCurrenThread that gives me the thread name....

CPallini9-Apr-08 7:55

CPallini

9-Apr-08 7:55

ForNow wrote:
I guess I could do GetCurrenThread

Good guess indeed.

ForNow wrote:
that gives me the thread name....

Actually it gives you the thread handle.
Smile | :)

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

ForNow9-Apr-08 12:46

9-Apr-08 12:46

Anyway to get more info ?? about the the threads Like thread Name ??

If I have a lot of threads and only a few that I really want to Process

I guess I have to Create a Process in Which with only those threads call DLL functions

Mark Salsbery9-Apr-08 12:58

9-Apr-08 12:58

I don't see anything documented anywhere about Win32 threads having names.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

ForNow9-Apr-08 13:09

9-Apr-08 13:09

The Last parm on CreateThread I thought that was a pointer to somehow Identifying the thread ...... (below)

I have a Windows Internals Book I am going to see if with a thread Handel I can somehow Identify the Thread

pThreadId

A pointer to a variable that receives the thread identifier. If this parameter is NULL, the thread identifier is not returned.

Return Value

Mark Salsbery9-Apr-08 13:11

9-Apr-08 13:11

ForNow wrote:
The Last parm on CreateThread I thought that was a pointer to somehow Identifying the thread

Yes, it is the unique identifier for the thread. You can also get it with GetCurrentThreadId(),
as I mentioned in my first reply.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

ForNow9-Apr-08 13:15

9-Apr-08 13:15

So SO Sorry ... You know people tell me this all the time My Boss or When I am dating

I just don't listen or read

Thankx

Mark Salsbery9-Apr-08 13:20

9-Apr-08 13:20

ForNow wrote:
or When I am dating

Who listens to them anyway hehe

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

ForNow9-Apr-08 13:25

9-Apr-08 13:25

thankx

Mark Salsbery9-Apr-08 8:05

9-Apr-08 8:05

GetCurrentThreadId() is useful to get the unique identifier for the thread.

The WMI Win32_Thread class has a little info - not much useful except for thread state.

To set the thread name seen in the debugger: How to: Set a Thread Name in Native Code[^]
I'm not sure how one gets the thread name programatically.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

cmk9-Apr-08 19:25

cmk

9-Apr-08 19:25

To set a thread name while debugging, as Mark mentioned:

void  utl::SetThreadName( cchar *NAME, DWORD ID )
{
	struct {
		DWORD   Type;   // must be 0x1000
		cchar  *Name;   // pointer to name (in user addr space)
		DWORD   Id;     // thread ID (-1=caller thread)
		DWORD   Flags;  // reserved for future use, must be zero
	}	info = { 0x1000, NAME, ID, 0 };
	__try
	{
		::RaiseException(0x406D1388, 0, sizeof(info)/sizeof(DWORD), (ULONG_PTR*)&info);
	}
	__except(EXCEPTION_CONTINUE_EXECUTION)
	{
	}
}

There is no way to get the name back.

If you really want to associate a name with a thread then use some variant of TLS.

When you get the THREAD_ATTACH is fairly well spelled out in the MSDN docs, what part don't you understand ?

...cmk

The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack

ForNow10-Apr-08 6:16

10-Apr-08 6:16

Hi, and thankx for responding

What my problem is that in my DLL_ATTACH_THREAD I only want to process only certin threads in my app So. I want to have some way of identfying them (the threads)

How about PsGetCurrentThread The seems to return a pointer to a ETHREAD block where I could some how identify from where this thread originated from

even though it was probably itended for device drivers the doc says any IRQL level

Thankx

cmk10-Apr-08 6:41

cmk

10-Apr-08 6:41

Just use the thread handle and thread id from either:
GetThreadId(thread_hnd)
GetCurrentThreadId()

From MSDN:
Until a thread terminates, its thread identifier uniquely identifies it on the system.

This means you must also track when a thread you are interested in dies.
For threads you start you can just catch DLL_THREAD_DETACH.
For others (e.g. started by MS CRT or nVidia OpenGL driver) you won't always get a DLL_THREAD_DETACH.

ForNow wrote:
some how identify from where this thread originated from

This is an unrelated issue, if you want to know that use StackWalk64 to trace the call stack.

ForNow10-Apr-08 13:48

Re: 32 bit version of StackWalk64

10-Apr-08 13:48

thank you

ForNow10-Apr-08 15:44