|
I think the more promising approach shown in the linked page is writing the address of folder in the edit box and then (programmatically) clicking the OK button (check out the final comments).
|
|
|
|
|
|
Thank's Richard, I have see the class...
I have that routine and in that routine I want change the dir.
Different dir for different extension.
I Try, but I'm not sure  )
|
|
|
|
|
Then you need to handle the notification message, as documented in that link.
|
|
|
|
|
Thank's Richard,
I'm using VC6++ and I need a simple example to understand..
my OnTypeChange()
{
if(m_ofn.nFilterIndex==1)
m_ofn.lpstrDefExt=".txt";
if(m_ofn.nFilterIndex==2)
m_ofn.lpstrDefExt=".doc";
if(m_ofn.nFilterIndex==1)
...code for change dir1
if(m_ofn.nFilterIndex==2)
...code for change dir2
}
I Try, but I'm not sure )
|
|
|
|
|
You need to check which property or method controls the current directory, and add code to manage it. Again the documentation will give you the information.
|
|
|
|
|
I don't use MFC but as it shims the Win32 I will explain how you do it in raw Win32.
The FILEOPEN dialog in common controls take a structure called OPENFILENAME one of it's fields is lpfnHook which allows you to install your own handler.
OPENFILENAMEA (commdlg.h) - Win32 apps | Microsoft Docs[^]
In your handler in the WM_NOTIFY message you handle the CDN_TYPECHANGE message
CDN_TYPECHANGE notification code (Commdlg.h) - Win32 apps | Microsoft Docs[^]
So a minimal handler looks like this
UINT_PTR CALLBACK OpenHookProc(HWND hDlg, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch (Msg)
{
case WM_NOTIFY:
{
LPOFNOTIFY pnh = (LPOFNOTIFY)lParam;
if (pnh && (pnh->hdr.code == CDN_TYPECHANGE))
{
switch (pnh->lpOFN->nFilterIndex)
{
case 0:
break;
case 1:
break;
}
}
break;
}
}
return (0);
}
In vino veritas
|
|
|
|
|
I already intercept CDN_TYPECHANGE in my OnTypeChange ()
...to change the directory what code I have to write where in your example you put the rem
// First extension type selected
and
// Second selection type selected
for list in my CFileDialog a different dir?
Thank's
I Try, but I'm not sure )
|
|
|
|
|
So just change directory then invalidate the dialog so it refreshes, you did all the hard part
SetCurrentDirectory function (winbase.h) - Win32 apps | Microsoft Docs[^]
Do remember if you want to go back to the original directory after the dialog closes, save the directory before you call the dialog with GetCurrentDirectory and the set it back when you exit.
In vino veritas
|
|
|
|
|
I changed the dir with SetCurrent Directory , I invalidated and I did UpdateData(false) for refresh but nothing happens ...
I Try, but I'm not sure )
|
|
|
|
|
I guess that UpdateData has nothing to do with what you are trying to achieve.
Could you post your actual code?
|
|
|
|
|
void MyClass::OnTypeChange()
{
if(m_ofn.nFilterIndex==2){ // .doc
char szPath [MAX_PATH] = {"c:\\DocFiles"};
SetCurrentDirectory(szPath);
} else { // .txt
char szPath2 [MAX_PATH] = {"c:\\TxtFiles"};
SetCurrentDirectory(szPath2);
}
Invalidate();
UpdateData(false);
// Here I want refresh the CFileDialog with the new filter and path
}
I Try, but I'm not sure )
|
|
|
|
|
No, this code won't work.
SetCurrentDirectory just sets the current directory. It cannot change the folder selection within the CFileDialog.
You have to find the possibility to change the folder selection within the CFileDialog control(s)!
|
|
|
|
|
ok, and what are these controls? can you send me an example code? Thank you
I Try, but I'm not sure )
|
|
|
|
|
Try instead to overwrite the m_ofn member lpstrFile to contain the full folder path,
either "c:\DocFiles" or "c:\TxtFiles".
|
|
|
|
|
sorry, it doesn't work 
I Try, but I'm not sure )
|
|
|
|
|
Could you post your implementation?
|
|
|
|
|
I try 2 solution:
void MyClass::OnTypeChange()
{
if(m_ofn.nFilterIndex==2){ // .doc
char szPath [MAX_PATH] = {"c:\\DocFiles"};
SetCurrentDirectory(szPath);
m_ofn.lpstrFile=szPath;
} else { // .txt
char szPath2 [MAX_PATH] = {"c:\\TxtFiles"};
SetCurrentDirectory(szPath2);
m_ofn.lpstrFile=szPath2;
}
Invalidate();
UpdateData(false);
}
and
void MyClass::OnTypeChange()
{
if(m_ofn.nFilterIndex==2){ // .doc
char szPath [MAX_PATH] = {"c:\\DocFiles\\file.doc"};
//SetCurrentDirectory(szPath);
m_ofn.lpstrFile=szPath;
} else { // .txt
char szPath2 [MAX_PATH] = {"c:\\TxtFiles\\file.txt"};
//SetCurrentDirectory(szPath2);
m_ofn.lpstrFile=szPath2;
}
Invalidate();
UpdateData(false);
}
But don't work.
N.B.: c:\DocFiles\file.doc and c:\TxtFiles\file.txt are existing files on the disk.
I Try, but I'm not sure )
|
|
|
|
|
Have you already customized your CFileDialog?
|
|
|
|
|
not yet
I Try, but I'm not sure )
|
|
|
|
|
In a winAPI project, I am generating dialog templates at compile time, but not setting the positions and sizes of the controls until runtime because they depend on the font, which I set to whatever the user has set as their lfMessageFont at runtime. One of the dialogs has an up-down control with a static control set as its buddy window. For the sake of consistency, I would like the up-down control to be positioned and sized according to the standards of the UDS_ALIGNRIGHT style. However, it seems that setting that style only suffices to position the up-down control according to the position and size of the buddy window as specified in the dialog template, and when I resize the buddy window when handling the dialog's WM_INITDIALOG message, the up-down control doesn't change with it. Is there a way to manually invoke the UDS_ALIGNRIGHT code again at this point? Or do I need to switch to generating the entire dialog template at runtime if I want to keep the effects of that style?
|
|
|
|
|
If you are adjusting size and position at run time, then you need to re-measure each control according to the new values that affect it. You also need to check any option settings on each control that may affect the layout. In your case the setting for UDS_ALIGNRIGHT will affect the control it is set on (the up/down) and the buddy window. See Up-Down Control Styles (CommCtrl.h) - Win32 apps | Microsoft Docs[^] for further information.
[edit]
You could load the resource dialog into memory and change the font details at runtime, and then invoke the dialog from the memory template. I am not 100% sure if that will work but a quick test should confirm it.
[/edit]
|
|
|
|
|
Inserting the font details into the template would save me having to send WM_SETFONT to every control in the dialog that has text while handling WM_INITDIALOG, as I do now, but I don't see what difference it would make in positioning the controls. One of the tools I use to determine the layout is Button_GetIdealSize, which I Can't call until I have an HWND for each control in question. As far as I can tell, that means I can't do it until I've instantiated an instance of the dialog. I guess I could instantiate an instance at startup, position and size the controls, alter the template to reflect the siz and position values this yields, then destroy the dialog. That way, each time an instance of the dialog is instantiated from then on, the layout will already be correct from the start. It seems like a rather tortured usage of the API, though.
I'm not sure what you mean by remeasuring each control. Out of context, I'd have guessed that would mean calling GetWindowRect on each control, but I believe I know what values that would return a priori; it should zero out the struct if I do it before reformatting the control, reflecting the zeroed-out dialog template, and if I do it after reformatting, it should return the values I just specified. I'm similarly confused about what it means to check the control's option settings.
|
|
|
|
|
|
I'm working on a project that involves an LL(k) parsing algorithm (or more accurately, a set of algorithms) which seem to be the best kept secret on the Internet.
The hunt for how to implement these took me back to C code written in 1989 and some citations for research papers dating back to 1992, which I can't seem to find a copy of the journal it was published in.
How do people even do LL(k)? How do they learn it? I understand how Terrence Parr (author of ANTLR) did as he has been instrumental in the crafting of LL(k) parsing algorithms for decades. He's no Aho & Ullman but he's a key player. He's the one that wrote that 1989 code I'm looking at.
I've found a few scattered research papers but the math is really heavy. You need a pretty advanced background in CS I think to understand it all.
But anyone else that wants to do this kind of thing? Good luck. If you can find the research it won't mean you can understand it, and I can't even find it, much less understand it. All the links are dead, and the citations I'm currently looking at lead to an out of print journal on information processing and information systems
It's ridiculous. No wonder there are so few implementations of this available (the major one by Terrence Parr himself)
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
