preventative directories
-
Hi All, I'm implementing a CFileDialog open/save as application using 6.0. My problem is trying to prevent the user from browsing above a specific directory, but allow them to browse the directories below it. I've tried many different approaches, but I still can't get it to work. At the moment I'm capturing the OnFolderChange message, which is produced after the user changes the folder he/she is browsing. In that method, I'm checking the current directory, and if it is outside of my directory range, then I thought I could just set the current working directory to what I need it to be, and then force the application to redraw. Here's the code:
void CLibselformdlg::OnFolderChange() { char buffer[MAX_PATH]=""; DWORD tmp; ::GetCurrentDirectory(MAX_PATH,buffer); tmp = ::GetLastError(); IUXLogData("are you ready\n",TRACE1); if (strstr(buffer,"C:\\iux\\data") == NULL){ ::SetCurrentDirectory("\\iux\\data"); tmp = ::GetLastError(); this->Invalidate(); // need to reset the list view and the combobox view with the new (original) folder // then refresh the display here. //::SendMessage(this->m_hWnd,WM_ERASEBKGND,(WPARAM)::GetDC(this->m_hWnd),NULL); //::SendMessage(this->m_hWnd,WM_PAINT,(WPARAM)::GetDC(this->m_hWnd),NULL); //this->UpdateWindow(); } }The SetCurrentDirectory I don't think works. The getlasterror returns a 183 after this function is run. You can see the different ways I've been trying to force the window to redraw with the new directory, but I'm not having any luck. Any Suggestions? :confused: Thanks alot! Dan -
Hi All, I'm implementing a CFileDialog open/save as application using 6.0. My problem is trying to prevent the user from browsing above a specific directory, but allow them to browse the directories below it. I've tried many different approaches, but I still can't get it to work. At the moment I'm capturing the OnFolderChange message, which is produced after the user changes the folder he/she is browsing. In that method, I'm checking the current directory, and if it is outside of my directory range, then I thought I could just set the current working directory to what I need it to be, and then force the application to redraw. Here's the code:
void CLibselformdlg::OnFolderChange() { char buffer[MAX_PATH]=""; DWORD tmp; ::GetCurrentDirectory(MAX_PATH,buffer); tmp = ::GetLastError(); IUXLogData("are you ready\n",TRACE1); if (strstr(buffer,"C:\\iux\\data") == NULL){ ::SetCurrentDirectory("\\iux\\data"); tmp = ::GetLastError(); this->Invalidate(); // need to reset the list view and the combobox view with the new (original) folder // then refresh the display here. //::SendMessage(this->m_hWnd,WM_ERASEBKGND,(WPARAM)::GetDC(this->m_hWnd),NULL); //::SendMessage(this->m_hWnd,WM_PAINT,(WPARAM)::GetDC(this->m_hWnd),NULL); //this->UpdateWindow(); } }The SetCurrentDirectory I don't think works. The getlasterror returns a 183 after this function is run. You can see the different ways I've been trying to force the window to redraw with the new directory, but I'm not having any luck. Any Suggestions? :confused: Thanks alot! Dan -
Hi All, I'm implementing a CFileDialog open/save as application using 6.0. My problem is trying to prevent the user from browsing above a specific directory, but allow them to browse the directories below it. I've tried many different approaches, but I still can't get it to work. At the moment I'm capturing the OnFolderChange message, which is produced after the user changes the folder he/she is browsing. In that method, I'm checking the current directory, and if it is outside of my directory range, then I thought I could just set the current working directory to what I need it to be, and then force the application to redraw. Here's the code:
void CLibselformdlg::OnFolderChange() { char buffer[MAX_PATH]=""; DWORD tmp; ::GetCurrentDirectory(MAX_PATH,buffer); tmp = ::GetLastError(); IUXLogData("are you ready\n",TRACE1); if (strstr(buffer,"C:\\iux\\data") == NULL){ ::SetCurrentDirectory("\\iux\\data"); tmp = ::GetLastError(); this->Invalidate(); // need to reset the list view and the combobox view with the new (original) folder // then refresh the display here. //::SendMessage(this->m_hWnd,WM_ERASEBKGND,(WPARAM)::GetDC(this->m_hWnd),NULL); //::SendMessage(this->m_hWnd,WM_PAINT,(WPARAM)::GetDC(this->m_hWnd),NULL); //this->UpdateWindow(); } }The SetCurrentDirectory I don't think works. The getlasterror returns a 183 after this function is run. You can see the different ways I've been trying to force the window to redraw with the new directory, but I'm not having any luck. Any Suggestions? :confused: Thanks alot! DanWhile I can't say for sure since I don't know the entire situation, it seems a better approach would be to set permissions at the OS level. That way, CFileDialog does not have to do anything special. It only "goes" where the user has permission to.
-
You need to look at hook functions for common dialogs, specifically handling CDN_FOLDERCHANGE and/or CDN_SELCHANGE. Steve S
-
While I can't say for sure since I don't know the entire situation, it seems a better approach would be to set permissions at the OS level. That way, CFileDialog does not have to do anything special. It only "goes" where the user has permission to.
That's an interesting idea. One that I like. But the people upstairs seem to want to go against what windows does with every other application so I'm stuck trying to limit directory access at this open/save as level. Any other ideas? Other than creating an open/save as dialog from scratch which IMO makes no sense at all to re-invent the wheel :~ Thanks guys! I appreciate it! Dan
-
That's an interesting idea. One that I like. But the people upstairs seem to want to go against what windows does with every other application so I'm stuck trying to limit directory access at this open/save as level. Any other ideas? Other than creating an open/save as dialog from scratch which IMO makes no sense at all to re-invent the wheel :~ Thanks guys! I appreciate it! Dan
will1383 wrote: ...which IMO makes no sense at all to re-invent the wheel. They don't seem to mind so why should you? Let it be known (to the powers that be) that such a solution is non-standard and prone to problems. I worked on a project once where it was decided that a dialog's "X" button and the Cancel button would each do different things. If the dialog was actually doing something, rather than just accepting input from the user, it had both Close and Cancel buttons. I hate it when goofy standards are put in place, only to propagate through the annals of the projects. Changing them requires an act of Congress.:mad: