|
Hi, I have a question.
Is there some mode in MFC to use the class CFileDialog inside a CPropertySheet ?
The goal can be extended to other CDialog classes that is necessary to use as CDialog but also as CPropertyPage without duplicate the code inside.
Thanks
Bye from Maxer
|
|
|
|
|
Maxer wrote:
Is there some mode in MFC to use the class CFileDialog inside a CPropertySheet ?
Do you mean from a CPropertyPage? If so, this should work:
CFileDialog fd(TRUE);
if (fd.DoModal() == IDOK)
{
...
}
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
No, what I would want is to see the CFileDialog in a tab of a CPropertySheet.
Is it possible?
Bye from Maxer
|
|
|
|
|
Maxer wrote:
No, what I would want is to see the CFileDialog in a tab of a CPropertySheet.
What do you think the tabs are? They are CPropertyPage objects. A CPropertySheet is comprised of two or more (yes, you can have one but that makes no sense) CPropertyPages.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Do you have try to add the CFileDialog object to a CPropertySheet object ?
CFileDialog is a CDialog derived class and not a CPropertyPage derived class.
Bye from Maxer
|
|
|
|
|
Maxer wrote:
Do you have try to add the CFileDialog object to a CPropertySheet object ?
No, the CFileDialog object is instantiated and used in one of the CPropertyPages.
Maxer wrote:
CFileDialog is a CDialog derived class and not a CPropertyPage derived class.
Of course. Did I imply otherwise?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Maybe that I'm not explained in the right way 
I know that a CFileDialog object can be created and used inside a CPropertyPage (for example when a button is pressed), but what I would want is to have a tab of the CPropertySheet that is a file browser (CFileDialog is a file browser so I would want to use it without to rewrite a new custom CPropertyPage class).
My question can be extended to all the times that is necessary to use a custom dialog that do something, but also to do the same things in a CPropertySheet tab. Is it possible to use a CDialog as CPropertyPage or a CPropertyPage as a CDialog ? My goal is to reuse all the code that is possible for fast maintenance of my project.
Bye from Maxer
|
|
|
|
|
What you are after cannot be achieved, at least that I know of. Each CPropertyPage object is "connected to" a dialog template in the project's resources. CFileDialog has its own dialog template in some other DLL (dialogs 1547 and 1552 of comdlg32.dll).
I don't see anything wrong with, on one of the tabs, having an edit control and a Browse button where, when clicked, would bring create a CFileDialog object. When a valid file is selected from that dialog, the edit control would reflect the selected file.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I want to code the Status Bar so that it displays the co-ordinates of mouse when i move the mouse. i created a pane for it and tried to handle the onmousemove event in the CMainFrame class but it didnt work.
Plz help me with it
|
|
|
|
|
|
hi:maybe ,i can help you some:the program i have run well,
void CMainFrame::OnViewStatusBar()
{
m_wndStatusBar.ShowWindow((m_wndStatusBar.GetStyle()&WS_VISIBLE)==0);
RecalcLayout();
}
void CMainFrame::OnUpdateViewStatusBar(CCmdUI* pCmdUI)
{
pCmdUI->SetCheck((m_wndStatusBar.GetStyle()&WS_VISIBLE)!=0);
}
void CMainFrame::OnUpdateLeft(CCmdUI* pCmdUI)
{pCmdUI->Enable(::GetKeyState(VK_LBUTTON)<0);
}
void CMainFrame::OnUpdateRight(CCmdUI* pCmdUI)
{
pCmdUI->Enable(::GetKeyState(VK_RBUTTON)<0);
}
void CStatusbool514View::OnMouseMove(UINT nFlags, CPoint point)
{
//CView::OnMouseMove(nFlags, point);
CString str;
CMainFrame* pFrame=(CMainFrame*)AfxGetApp()->m_pMainWnd;
CStatusBar* pStatus=&pFrame->m_wndStatusBar;
if(pStatus)
{
str.Format("x=%d",point.x);
pStatus->SetPaneText(0,str);
str.Format("y=%d",point.y);
pStatus->SetPaneText(1,str);
}
}
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{.......
if (!m_wndStatusBar.Create(this,
WS_CHILD|WS_VISIBLE|CBRS_BOTTOM,ID_MY_STATUS_BAR)||
!m_wndStatusBar.SetIndicators(indicators, sizeof(indicators)/sizeof(UINT)))
{
TRACE0("Failed to create status bar\n");
return -1; // fail to create
}
}
static UINT indicators[] =
{
ID_SEPARATOR,
ID_SEPARATOR,
ID_INDICATOR_LEFT,//(3)(4)you yourself define in string table
ID_INDICATOR_RIGHT,// status line indicator
};
|
|
|
|
|
Hi
In the past thread, i asked about C++ exception handling using __try, __except and _try __finally blocks to safeguard my codes against carelessness programming as well as unforeseen events... I am using on a embedded WinCE platform
after almost completing my module, i find that the size of the programs grows a lot, from the initial 10k to abt 100k. Is there anyway to minimise the size and at the same time without compromise reliably.
The size is critical as my program may need to upgrade through IR and if it is huge, time is a factor but i can't sacrifice for a reliable program
any help pls??
thanx
|
|
|
|
|
IceBerG71 wrote:
...the size of the programs grows a lot, from the initial 10k to abt 100k
Are you relating the growth directly to the inclusion of exception handling?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Yes, the size was a result of adding the excpetion blocks, maybe i use too extensive, every functions i use the exception to protect the codes in case there is any errors resulting in unforseen cases. initially, it helps me in debugging, after solving the bugs, so far, the exception was never resulted but frankly speaking, it is hard to predict what user can do to it since there is user entry portion.
I checked MS website, it was indicated that the __try __ except is WIN32 exception handling. and they also indicated not all cases can be captured by the __try block.
|
|
|
|
|
If size is critical, don't use exceptions for careless programming, only to actually catch critical errors outside your control. You could also drop C++ exception handling entirely and use only Win32 structured exception handling.
(My opinion may be unpopular, but C++ exception handling itself does not ensure a reliable program. It helps clean up the stack, but in the end, is just another error handling mechanism. I use exceptions very sparingly; mainly where other error handling techniques grow more cumbersome than if I had used exceptions.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
FWIW '__try/__except/__finally' aren't C++ exception handling, it's (AFAIK) an MS enhancement to their C and C++ compilers that allows code to be generated for Win32 Structured Exception Handling. In the Windows world C++ exceptions are built on top of this.
This obviously doesn't help you, but getting the terminology right cannot hurt...
Paul
|
|
|
|
|
I have a libray which sets up shared memory and an event to
schedule some processing (display data, quite larger) in a GUI (a separate thread in the GUI will process this event).
All works fine if I use timers to do the display of the data, however if I opt for Events then the Shared Memory pointer 'm_pMsg' goes invalid following the first event.
So Shared Memory does not work with Events - Am I missing something
Could someone have a good at the code sections below and see if this scheme is correct
In the Library (Loaded DLL)
m_hMap = ::CreateFileMapping((HANDLE)0xFFFFFFFF,NULL,PAGE_READWRITE,0,
sizeof(TSharedMemory),
"CSLSharedMem");
// Obtain a pointer from the handle to file mapping object
m_pMsg = (TSharedMemory*)::MapViewOfFile(m_hMap,FILE_MAP_WRITE,0,0,sizeof(TSharedMemory));
// Set up an event for the GUI to process the Display Text
hGlobalWriteEvent = CreateEvent(NULL, // no security attributes
TRUE, // manual-reset event
FALSE, // initial state is signaled
"CSLDisplayData" // object name
);
// Signal GUI to process this request
::SetEvent(hGlobalWriteEvent);
Now in the GUI (Main)
// Try to create file mapping object (assume that this is the server)
m_hMap = ::CreateFileMapping((HANDLE)0xFFFFFFFF,NULL,PAGE_READWRITE,0,
sizeof(TSharedMemory),
"CSLSharedMem");
// Check if file mapping object already exists. If it does, then this is a
// client and in this case open existing file mapping object. Client also
// needs to create a mutex object to synchronize access to the server
if (GetLastError() == ERROR_ALREADY_EXISTS)
{
m_hMap = ::OpenFileMapping(FILE_MAP_WRITE,FALSE,"CSLSharedMem");
m_strOutput+= "File Already Exists - This is the Client " + crlf;
SetDlgItemText(IDC_OUTPUT, m_strOutput);
UpdateData();
}
else
{
MessageBox("File Mappings Hove Not Been Setup - Check WHLLIB.DLL");
m_strOutput+= "Warning - This is the Server " + crlf;
SetDlgItemText(IDC_OUTPUT, m_strOutput);
UpdateData();
}
// Obtain a pointer from the handle to file mapping object
m_pMsg = (TSharedMemory*)::MapViewOfFile(m_hMap,FILE_MAP_WRITE,0,0,sizeof(TSharedMemory));
In the GUI Thread
UINT CTestGUI1Dlg::DisplayTextThread(LPVOID param)
{
/* This is the thread function for the Display Data. The structure contains a stop flag and the 'this'
pointer for access to the dialog properties. */
DisplayThreadData* ThreadData = (DisplayThreadData*)param;
CTestGUI1Dlg* pxDlg = (CTestGUI1Dlg*) ThreadData->_this; // (CMyDialog*) pxDlg = (CMyDialog*) pParam;
// Set up an event for the GUI to process the Display Text
hGlobalWriteEvent = CreateEvent(NULL, // no security attributes
TRUE, // manual-reset event
FALSE, // initial state is signaled
"CSLDisplayData" // object name
);
while(!ThreadData->stopFlag)
{
if (::WaitForSingleObject(hGlobalWriteEvent, INFINITE) == WAIT_OBJECT_0)
{
// AfxMessageBox("Event Fired");
pxDlg->UpdateOutput();
}
}
return 0;
}
Help
|
|
|
|
|
Global events and shared memory have no relationship, apart from using the global namespace, etc..
You scheme is fundamentally valid, though, as you stated, you may want to add a mutex so the shared memory can be locked.
I don't like how you pass the pointer of the dlg into the thread; it seems awfully convoluted. Why not just pass the this pointer as the param?
The second potential problem is pxDlg->UpdateOutput(). This is the most likely candidate for a memory overwrite of your m_pMsg pointer. (The shared memory is very likely still there, (Verify with this utility: http://www.sysinternals.com/ntw2k/freeware/procexp.shtml[^])
A few other concern: You may be handling CTestGUI1Dlg incorrectly. You should use PostThreadMessage to do more than trivial things in a CWnd derived object from a secondary thread.
In your loop, you don't check stopFlag immediately upon the wait being satisfied. When shutting down, this could cause problems if the dialog is destructed earlier than hGlobalWriteEvent is set.
The event is a manual event, but isn't being reset.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Thanks for your comments on the code.
All I am trying to do is have an Edit Box (Multi-line, vertical scroll) display text posted via a call to DLL. The thread handles the Event from the DLL but needed access to the dialogs classes.
I don't like how you pass the pointer of the dlg into the thread; it seems awfully convoluted. Why not just pass the this pointer as the param?
That why I pass in the dialog pointer (this) and the stop flag.
The structure is as follows:-
// For Display Text Thread
typedef struct
{
bool stopFlag; // Set if some error occured during the process or want to terminate
CTestGUI1Dlg* _this;
}DisplayThreadData;
The second potential problem is pxDlg->UpdateOutput(). This is the most likely candidate for a memory overwrite of your m_pMsg pointer.
Whats the alternative, as if I comment this call out, program does not crash (but does not display the text. I think you are right, this is where the problem is!!!
But what to do?
A few other concern: You may be handling CTestGUI1Dlg incorrectly. You should use PostThreadMessage to do more than trivial things in a CWnd derived object from a secondary thread.
Sorry you have passed the limit of my knowledge.
I was using a timer to process the text display, but had to slow things down (on both size) to be sure of not losing data.
Was advised that reacting to events would be better.
But ended up with a different problem.
Have now set Event to Auto reset and sorted out the terminate logic.
Sweep123 working from home.
grahamfff
|
|
|
|
|
Grahamfff wrote:
That why I pass in the dialog pointer (this) and the stop flag.
My mistake; based on past experience I assumed you were passing some convoluted thing.
Grahamfff wrote:
A few other concern: You may be handling CTestGUI1Dlg incorrectly. You should use PostThreadMessage to do more than trivial things in a CWnd derived object from a secondary thread.
Sorry you have passed the limit of my knowledge.
In MFC, you aren't supposed to call any control objects owned by one thread from another. You can do it, but it can cause problems [usually reentrancy problems.] The proscribed solution is to use PostThreadMessage with the handle of the window in question, in this case the dialog box, with a USER message or even a "fake" valid message. (Try creating a fake WM_TIMER message.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
such as tips, compiler setting, shortcut key...
|
|
|
|
|
|
|
Hi, I have a question.
Is there any way to play a MJPEG file with Windows Media Player?
Thanks
|
|
|
|
|
yes. but you'll need an MJPEG codec to do it. there are many commercial codecs available... don't know of any free ones...
Cleek | Jewelry | ClickPic | ThumbNailer
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
