C / C++ / MFC

Re: getting pointer to document from OnGetTabToolTip in MDI tabbed app

12-Sep-13 6:41

I am trying to get a pointer to my CDocument derived class associated with a particular tab index (provided by the MDI tab control). The MFC framework calls my OnGetTabToolTip function and provides a CMFCTabToolTipInfo pointer which contains in index of the tab requiring the tooltip text... but it seems there is no way to retrieve the doc/view associated with the tab! Must I keep track of the tab index-doc association, keeping in mind users can move tabs around willy nilly, or is there a better way?

I would have thought this had been discussed countless times, but I cannot find helpful advice.

Many thanks.

David Crow12-Sep-13 16:10

David Crow

12-Sep-13 16:10

See here.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

Re: getting pointer to document from OnGetTabToolTip in MDI tabbed app

Member 258447412-Sep-13 18:01

Re: getting pointer to document from OnGetTabToolTip in MDI tabbed app

12-Sep-13 18:01

Thank you for the reply. Unfortunately, your link does not help solve the problem I described. Perhaps some code will clarify the issue. My ToolTip handler looks like this:

C++

LRESULT CMainFrame::OnGetTabToolTip(WPARAM wp, LPARAM lp)
{
	CMFCTabToolTipInfo* pInfo = (CMFCTabToolTipInfo*) lp;
	ASSERT (pInfo != NULL);
 
	if (pInfo)
	{
		ASSERT_VALID (pInfo->m_pTabWnd);
		if (!pInfo->m_pTabWnd->IsMDITab ())
		{
			return 0;
		}
 
		CWnd *pwnd = pInfo->m_pTabWnd->GetTabWnd(pInfo->m_nTabIndex);
                // CMyDoc *pDoc = get document from pwnd using pInfo->m_nTabIndex somehow ???
		pInfo->m_strText = pDoc->GetTabTipString();
	}
 
	return 0;
}

As you can see, a method for getting a pointer to the CDocument derived object CMyDoc from pwnd is needed. From what I have gathered so far, pwnd is a CWnd * to the tab control, and casting it to a (CMyDoc *) does NOT provide a valid pointer (I have tried).

Because the act of clicking on the tab activates the correct doc/view (which is the whole point of having a tabbed MDI), there should be some way of getting a pointer to it.. but I cannot see how this is done.

Member 258447412-Sep-13 18:04

Re: getting pointer to document from OnGetTabToolTip in MDI tabbed app

12-Sep-13 18:04

Also, I should emphasize that the CMyDoc pointer is not necessarily the active document. It can be any document associated with a tab.

jeron113-Sep-13 5:20

jeron1

13-Sep-13 5:20

Could you possibly subclass the tab control and add a member (pointer to doc) that you fill in or retrieve as necessary?

Re: getting pointer to document from OnGetTabToolTip in MDI tabbed app

Member 258447413-Sep-13 7:39

Resizing Controls and Texts

13-Sep-13 7:39

I am using the CMDIFrameWndEx class which has built-in support for tabbed documents.

So I figured out what the problem was. Turns out, the function CFrameWnd::GetActiveDocument() returns precisely what is needed: the document associated with the tab over which the mouse is hovered. This is not the same as the currently active document, in the usual sense (the open tab). Sank a lot of time into this one Mad | :mad:

Thanks for the replies!

Don Guy11-Sep-13 14:00

Don Guy

11-Sep-13 14:00

Hello all,

I have a SDI application that uses a CFormView class to create a window and this window has 2 buttons and 2 edit boxes.

I can resize this window, like minimize and maximize, but the controls all stay at the same place.

I know that it's possible to move the controls based on window size.

But what i want to do is, as the window is expanded the controls and it's text content to grow proportionally and same when the window is shrinked.

Is that possible to do? i.e., increase/decrease size of controls and texts per window size.

Any sample code will help.

Thanks in advance.

Re: Resizing Controls and Texts

digitalspace.xjtu11-Sep-13 15:02

digitalspace.xjtu

11-Sep-13 15:02

OnSize() method which respond to the change of windows could do this job

C++

// Resize the list control contained in the view to
// fill the entire view when the view's window is
// resized. CMyView is a CView derived class.
void CMyView::OnSize(UINT nType, int cx, int cy)
{
   CView::OnSize(nType, cx, cy);
   // Resize list to fill the whole view.
   m_List.MoveWindow (0, 0, cx, cy);
}

1. keep the original size of dialog, suppose Old_width is original width of dialog. We also deal with the height like this

2. use GetWindowRect( LPRECT lpRect ), which Copies the dimensions of the bounding rectangle of the CWnd object to the structure pointed to by lpRect. From it
you get New_Width (it is new width of dialog now)

3. calculate rate = Old_width/ New_Width .

4. use

C++

CWnd* GetDlgItem(
   int nID
) const;

to get pointer(suppose ptr) of button or other control,
use ptr->GetWindowRect( BtnRect ) to get boundary rect of button ( or other ..)
calculate new rect of button( suppose new_btn_rect ) through rate and BtnRect (the height also shoud be consided)

5. use ptr->MoveWindows(new_btn_rect ) to move button and change its size

Re: Resizing Controls and Texts

SoMad11-Sep-13 17:16

SoMad

11-Sep-13 17:16

There are several ways to do the re-positioning of controls. If you just want to experiment a bit for yourself, you can start by following the first answer and familiarize yourself with the functionality. If you want to see how others have done it, here are a couple of CodeProject articles:
MFC/C++ Helper Class for Window Resizing[^]
Control Positioning and Sizing using a C++ Helper Class[^]
Simple and more powerful resizable dialog[^]
EasySize - Dialog resizing in no time![^]
ResizableLib[^]

There are several other articles, just follow the "Related Articles" links in the right hand side bar on the article pages.

My final suggestion is to be prepared to drop the idea of resizing the text. I was involved with a project many years ago where we had to do exactly what you have described and we ended up throwing it away because we were unable to make it look good in all cases. Especially handling text on buttons kept causing problems.
As I said, it was a long time ago, so maybe you can find a solution that works well for you.

Soren Madsen

"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

What is doscreatemutexsem

Carl Cioffi11-Sep-13 9:57

Carl Cioffi

11-Sep-13 9:57

I'm not a C++ programmer but have a question about a particular piece of code and what is exactly it's purpose. It runs in a windows service and has been flagged as being a race condition issue.

DosCreateMutexSem(SemaphoreName,&SemaphoreHandle,0l,FALSE);

Exactly what does this line of code do and why would it be needed in a windows service?

David Crow11-Sep-13 10:33

David Crow

11-Sep-13 10:33

Carl Cioffi wrote:

Exactly what does this line of code do and why would it be needed in a windows service?

Have you tried this?

Carl Cioffi12-Sep-13 3:20

Carl Cioffi

12-Sep-13 3:20

Ok, so I get the whole mutex/semaphore/lock concept but explain to me why the one line of code would cause a race condition. Is this really a race condition or is it just the old ounce scan software we are using. It's not like the createmutex is waiting for something and spinning. I don't really see it as a valid race condition.

David Crow12-Sep-13 3:36

David Crow

12-Sep-13 3:36

Carl Cioffi wrote:
I don't really see it as a valid race condition.

Given the context in which you've shown it, it's impossible to say. A race condition is when two logic paths race to be the first to influence the output. What you've shown is simply a function call.

Run MFC Program Without Dialog Showing

Carl Cioffi12-Sep-13 3:55

Carl Cioffi

12-Sep-13 3:55

Well, it's a windows service that creates a number of mutexes and then create several listener threads that listen for credit/debit/gift card transactions. I assume the mutexes are used to lock the threads while a transaction is being processed. Given the scenario, I see the mutex creation is performed when the windows service is first started so I just don't see how a race condition could occur unless the service tried to start up twice concurrently. The following function is called once at the startup of the service. I just don't see it. It's a service waiting for a message on a specific port and just sits there and spins until such time. It never tries to execute any of the doscreatemutexsem functions after that.

void InitDebit() {

   int  rc;

   Log(DEBUG_ALWAYS,"Initializing US Debit");

   // Create and open the debit semaphore
   rc = DosCreateMutexSem(FingerPrintSemaphoreName,&FingerPrintSemaphoreHandle,0,0);

   if (rc) {
      Log(DEBUG_ERROR,"FingerPrint DosCreateMutexSem %d",rc);
   }

}  // end InitDebit

Andraw11110-Sep-13 6:53

10-Sep-13 6:53

Hi, dear all,

I have a MFC program which do some calculation, store in a file, then plot the results to a graphic on dialog.

Now I have another program which only want to use the calculation result stored in file from above MFC program but don't want to show the dialog, how can I do it?

I modify the codes in InitInstance() as below:

m_pMainWnd->ShowWindow(SW_HIDE);
m_pMainWnd->UpdateWindow();
return FALSE;

the dialog is not shown, but user still can see the dialog flush before hiding, how can I avoid it?

Thanks!

Alan Balkany10-Sep-13 7:58

Alan Balkany

10-Sep-13 7:58

Maybe you could give the window zero width and height before it's shown.

Andraw11110-Sep-13 8:20

10-Sep-13 8:20

Alan,

Thank you for yoru reply.

In PreCreateWindow(CREATESTRUCT& cs)

I set:

cs.cy = 0.0;
cs.cx = 0.0;
cs.y = 0;
cs.x = 0;

return CFormView::PreCreateWindow(cs);

But there still have flush of the dialog.

Alan Balkany10-Sep-13 8:23

Alan Balkany

10-Sep-13 8:23

Hmm... Maybe you could try: ShowWindow(SW_MINIMIZE);

Andraw11110-Sep-13 11:11

10-Sep-13 11:11

I try it, but you can see the process that the dialog is minimized, that's not what I expected.
Thanks!

Alan Balkany10-Sep-13 11:39

Alan Balkany

10-Sep-13 11:39

Another idea: Use this: http://msdn.microsoft.com/en-us/library/kc4ez6dk%28v=vs.90%29.aspx[^]

to lock the window while you bring up the dialog, with the window hidden. LockWindowUpdate may prevent the flash while the dialog is displayed then hidden.

Richard MacCutchan10-Sep-13 10:42

Richard MacCutchan

10-Sep-13 10:42

Take the calculation code and move it to a separate source file so you can add it to different projects.

Veni, vidi, abiit domum

Andraw11110-Sep-13 11:13

10-Sep-13 11:13

Richard,

Thanks for reply. the existing program is used by several projects, soome want the dialog, some not. so I just want to pass a argument to indicate show dialog or not.

Richard MacCutchan10-Sep-13 11:31

Richard MacCutchan

10-Sep-13 11:31

OK, so accept a parameter and if it's false do not show the dialog, something like:

C++

int APIENTRY WinMain(HINSTANCE hInstance,       // instance value of the invoked application
                     HINSTANCE hPrevInstance,   // no longer used
                     PSTR      pszCmdLine,      // pointer to the MS-DOS command line
                     int       nCmdShow         // value indicating initial state of the window
                     )
{
    BOOL myParameter;
    // get the parameter from the command line and convert to BOOL

    if (myParameter == TRUE)
    {
        DialogBoxParam(hInstance,
                       MAKEINTRESOURCE(IDD_DLG),
                       NULL,
                       (DLGPROC)DlgProc,
                       NULL
                       );
    }
    else
    {
        // call the function to calculate and write the file
    }

    return TRUE;
}

Where is the problem?

Veni, vidi, abiit domum