|
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
|
|
|
|
|
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:
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);
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.
|
|
|
|
|
Also, I should emphasize that the CMyDoc pointer is not necessarily the active document. It can be any document associated with a tab.
|
|
|
|
|
Could you possibly subclass the tab control and add a member (pointer to doc) that you fill in or retrieve as necessary?
|
|
|
|
|
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 
Thanks for the replies!
|
|
|
|
|
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.
|
|
|
|
|
OnSize() method which respond to the change of windows could do this job
void CMyView::OnSize(UINT nType, int cx, int cy)
{
CView::OnSize(nType, cx, cy);
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
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
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
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?
"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
|
|
|
|
|
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.
|
|
|
|
|
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.
"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
|
|
|
|
|
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");
rc = DosCreateMutexSem(FingerPrintSemaphoreName,&FingerPrintSemaphoreHandle,0,0);
if (rc) {
Log(DEBUG_ERROR,"FingerPrint DosCreateMutexSem %d",rc);
}
}
|
|
|
|
|
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!
|
|
|
|
|
Maybe you could give the window zero width and height before it's shown.
|
|
|
|
|
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.
|
|
|
|
|
Hmm... Maybe you could try: ShowWindow(SW_MINIMIZE);
|
|
|
|
|
I try it, but you can see the process that the dialog is minimized, that's not what I expected.
Thanks!
|
|
|
|
|
|
Take the calculation code and move it to a separate source file so you can add it to different projects.
Veni, vidi, abiit domum
|
|
|
|
|
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.
|
|
|
|
|
OK, so accept a parameter and if it's false do not show the dialog, something like:
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pszCmdLine, int nCmdShow )
{
BOOL myParameter;
if (myParameter == TRUE)
{
DialogBoxParam(hInstance,
MAKEINTRESOURCE(IDD_DLG),
NULL,
(DLGPROC)DlgProc,
NULL
);
}
else
{
}
return TRUE;
}
Where is the problem?
Veni, vidi, abiit domum
|
|
|
|
|
Following Richard's idea , if you program based on MFC Dialog , I think you can change InitialInstance() like this
...........
BOOL myParameter;
CMFCApplication4Dlg *pMainWnd = new CMFCApplication4Dlg;
if(myParameter) {
pMainWnd->DoModal();
}else { pMainWnd->CreateEx(NULL,_T("STATIC"), L"Hi", WS_BORDER , CRect(-15, -15, -15, -15), NULL,NULL);
}
........
|
|
|
|
|
I wouldn't create the main window at all if no Dialog/MainFrame is needed. Just call the class doing the processing from InitInstance(), if no window is requested. The program will end automatically when the processing is complete.
In case of the windowed mode you can start the same processing from a button click or menu item click.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Hi, dear all,
I solve this issue, thanks for all of you for your help.
inside InitInstance() function
m_nCmdShow = SW_HIDE;
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
.........
.......
.......
m_pMainWnd->ShowWindow(m_nCmdShow);
m_pMainWnd->UpdateWindow();
return FALSE;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
