HMGforum.com

Posted: **Thu Dec 18, 2014 9:41 pm**

Hi Kevin,

I have one doubt. At first parameter we need to inform a acFilter as array. You make some changing for nIndex that it will index into the filter array. But tell me if I put in my order this array, should it be quite the same propose ?

I have another question about 3rd parameter of GetFile, which is a simple variable. But if we have an array (with different kind of files) should it be this 3rd parameter an array too ? Because I wish to have different default positioning for each kind of files. It would not seem as normal and appropriate that idea ? I.e. accepting as array too ?

I do not want to blame you (how could I do it ?) only because you were the author of this topic. But taking advantage of the title/subject I would like to make one more observation:

Actually the 3rd parameter for GetFile (cDefaultPath) is needed to add this +"\" (backslash at final of path). IMHO, should NOT be like this (for example):

cDefaultPath := "C:\Program Files\Notepad++"+"\"

In the normal use should it be like this:

cDefaultPath := "C:\Program Files\Notepad++"

All these my comment, is just my observations. If I am wrong or you considere right, please comment. The final goal is to improve resources.

Posted: **Fri Dec 19, 2014 4:03 am**

Pablo César wrote:I have one doubt. At first parameter we need to inform a acFilter as array. You make some changing for nIndex that it will index into the filter array. But tell me if I put in my order this array, should it be quite the same propose ?

I don't understand what you're saying.

In GetFile and PutFile, the nIndex argument simply tells Windows which of the filters you provided is displayed by default. The user can then change the filter to one of the other filters you provided. The order used for nIndex is the order in which you specified the filters. If your filter array is {{'Text files', '*.txt'}, {'RTF files', '*.rtf}} and you set nIndex to 2, then the RTF filter will be displayed by default.

I've tested these changes and am now using them in my programs, so I don't regard them as merely proposals.

Pablo César wrote:I have another question about 3rd parameter of GetFile, which is a simple variable.

This is the default folder. I did not make any changes to this parameter.

Pablo César wrote:But if we have an array (with different kind of files) should it be this 3rd parameter an array too ? Because I wish to have different default positioning for each kind of files. It would not seem as normal and appropriate that idea ? I.e. accepting as array too ?

This parameter is the default folder, the folder which is displayed when the dialog first comes up. There can be only one such folder. The user can change this folder, unless you set the 5th parameter, lNoChangeDir.

The return value is either a full path (including folder), or an array of full paths (including folders), that the user selected. If the user selects multiple files, I believe that they all have to be in the same folder. But even if they are in different folders, the return array will contain a full path name for each file.

Pablo César wrote:Actually the 3rd parameter for GetFile (cDefaultPath) is needed to add this +"\" (backslash at final of path). IMHO, should NOT be like this (for example):

cDefaultPath := "C:\Program Files\Notepad++"+"\"

In the normal use should it be like this:

cDefaultPath := "C:\Program Files\Notepad++"

I believe Windows will accept a path with or without a trailing backslash.

Kevin

Posted: **Fri Dec 19, 2014 12:14 pm**

Thank you Kevin!

Posted: **Fri Dec 19, 2014 3:03 pm**

Thanks for your reply Kevin ! But please note all my questions was not directed only to you. Please see only first question was exclusively to you. Of course all comments, opinion and clarifications about my doubts is always very welcomed from you and for any one.

kcarmody wrote:
Pablo César wrote:I have one doubt. At first parameter we need to inform a acFilter as array. You make some changing for nIndex that it will index into the filter array. But tell me if I put in my order this array, should it be quite the same propose ?
I don't understand what you're saying.

In GetFile and PutFile, the nIndex argument simply tells Windows which of the filters you provided is displayed by default. The user can then change the filter to one of the other filters you provided. The order used for nIndex is the order in which you specified the filters. If your filter array is {{'Text files', '*.txt'}, {'RTF files', '*.rtf}} and you set nIndex to 2, then the RTF filter will be displayed by default.

Some time, good examples is equyivalent for thousand words.

So please note, if we have for first parameter in GetFile following array: {{'Text files', '*.txt'}, {'RTF files', '*.rtf}} and let say programmer wants to let first as default the second element of the array and also let say the nIndex parameter was not implemented yet. You can make your array with your predefined array already ordered (for second element be first), like this: {{'RTF files', '*.rtf},{'Text files', '*.txt'}}.

I'm explaining why you did not understand me and my intention is not wishing to belittle, just question whether both procedures would have the same result, the same purpose. Is not it ?

kcarmody wrote:
Pablo César wrote:I have another question about 3rd parameter of GetFile, which is a simple variable.
This is the default folder. I did not make any changes to this parameter.

This my question is not complete, but was made not only for you specifically. I know you do not modifyied this 3rd parameter. But I wish to ilustrate that it could be different if we change this.

kcarmody wrote:
Pablo César wrote:But if we have an array (with different kind of files) should it be this 3rd parameter an array too ? Because I wish to have different default positioning for each kind of files. It would not seem as normal and appropriate that idea ? I.e. accepting as array too ?
This parameter is the default folder, the folder which is displayed when the dialog first comes up. There can be only one such folder.

What I mean, changing codes to accept the 3rd parameter as array, it will be posible to have more than one default folder. Because it will be displayed and positioned at each case of 1st parameter. In other words:

If I have this {{'Text files', '*.txt'}, {'RTF files', '*.rtf}} as 1st parameter and be posible to have the 3rd parameter as an array like this: {"C:\My documents\Text files\","C:\My documents\Rich files\"} then for each element I could have different folder to be displayed/positioned.

kcarmody wrote:The user can change this folder, unless you set the 5th parameter, lNoChangeDir.

I thought when 5th parameter i being setted as .F. it was only for positioning folder at returns. (Here to see Claudio's indication)

kcarmody wrote:
Pablo César wrote:Actually the 3rd parameter for GetFile (cDefaultPath) is needed to add this +"\" (backslash at final of path). IMHO, should NOT be like this (for example):

cDefaultPath := "C:\Program Files\Notepad++"+"\"

In the normal use should it be like this:

cDefaultPath := "C:\Program Files\Notepad++"
I believe Windows will accept a path with or without a trailing backslash.

Not in this case (in GetFile), Kevin. I have tested without backslash and not is showing specific extension files.

So Kevin, your comments are very welcomed but I also expect some other changings in GetFile:

1. The 6th parameter, it is ok for me. Until now, probably I did not understood the real goal of it (sorry if I mssunderstood), but do not need to change.

2. The 3rd parameter, could accept array or simple variable. In array one, allows to pre-define different paths for default folder to be displayed.

3. The 3rd parameter, accepts both ways: with and withour backslash at end of path.

But all of this is my point of view. Probably I am wrong.

And I accept Claudio opinion and others ones comments. I just used this topic because it is same subject only (except only for 1st question to the author of topic).

Posted: **Fri Dec 19, 2014 9:11 pm**

Pablo César wrote:So please note, if we have for first parameter in GetFile following array: {{'Text files', '*.txt'}, {'RTF files', '*.rtf}} and let say programmer wants to let first as default the second element of the array and also let say the nIndex parameter was not implemented yet. You can make your array with your predefined array already ordered (for second element be first), like this: {{'RTF files', '*.rtf},{'Text files', '*.txt'}}.

I'm explaining why you did not understand me and my intention is not wishing to belittle, just question whether both procedures would have the same result, the same purpose. Is not it ?

Almost the same result. The difference would be that the filter list would be in a different order from one that the users are used to. In my case, I wanted to always display the filter list in the same order and display a different default filter.

Pablo César wrote:
kcarmody wrote:
Pablo César wrote:But if we have an array (with different kind of files) should it be this 3rd parameter an array too ? Because I wish to have different default positioning for each kind of files. It would not seem as normal and appropriate that idea ? I.e. accepting as array too ?
This parameter is the default folder, the folder which is displayed when the dialog first comes up. There can be only one such folder.

What I mean, changing codes to accept the 3rd parameter as array, it will be posible to have more than one default folder. Because it will be displayed and positioned at each case of 1st parameter. In other words:

If I have this {{'Text files', '*.txt'}, {'RTF files', '*.rtf}} as 1st parameter and be posible to have the 3rd parameter as an array like this: {"C:\My documents\Text files\","C:\My documents\Rich files\"} then for each element I could have different folder to be displayed/positioned.

Windows does not easily allow you to do this. The HMG function GetFile() is basically a shell for the Windows function GetOpenFileName(), which uses the Windows OPENFILENAME structure. This structure does not allow the default folder to be an array, just a scalar value. In order to implement your suggestion, someone would have to write a variant of GetOpenFileName() out of more primitive components. That's a pretty big piece of C programming, and it's not worth it to me.

Pablo César wrote:
kcarmody wrote:The user can change this folder, unless you set the 5th parameter, lNoChangeDir.
I thought when 5th parameter i being setted as .F. it was only for positioning folder at returns. (Here to see Claudio's indication)

I don't know what you mean by "positioning folder at returns." The 5th parameter controls whether the user can change the folder from the one you set in the 3rd parameter. Claudio's message does not indicate anything other than the default value for the 5th parameter.

Pablo César wrote:
kcarmody wrote:
Pablo César wrote:Actually the 3rd parameter for GetFile (cDefaultPath) is needed to add this +"\" (backslash at final of path). IMHO, should NOT be like this (for example):

cDefaultPath := "C:\Program Files\Notepad++"+"\"

In the normal use should it be like this:

cDefaultPath := "C:\Program Files\Notepad++"
I believe Windows will accept a path with or without a trailing backslash.
Not in this case (in GetFile), Kevin. I have tested without backslash and not is showing specific extension files.

I just tested it and find that the trailing backslash is not needed -- GetFile goes to the folder you name in the 3rd parameter, whether or not it has a trailing backslash, and the files that is shows match the default filter and any other filter the user selects.

Kevin

Posted: **Fri Dec 19, 2014 11:40 pm**

Thank you Kevin for your kind of attention.

kcarmody wrote:Windows does not easily allow you to do this. The HMG function GetFile() is basically a shell for the Windows function GetOpenFileName(), which uses the Windows OPENFILENAME structure. This structure does not allow the default folder to be an array, just a scalar value. In order to implement your suggestion, someone would have to write a variant of GetOpenFileName() out of more primitive components. That's a pretty big piece of C programming, and it's not worth it to me.

Thank you for your suggestion, but is not is not feasible. The strange that I read this:

: Screen1.png (29.48 KiB) Viewed 6522 times

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

But I tested in Win7 and when the 3rd parameter is not informed not assume that.

kcarmody wrote:
Pablo César wrote:The user can change this folder, unless you set the 5th parameter, lNoChangeDir.
I thought when 5th parameter i being setted as .F. it was only for positioning folder at returns. (Here to see Claudio's indication)
I don't know what you mean by "positioning folder at returns." The 5th parameter controls whether the user can change the folder from the one you set in the 3rd parameter. Claudio's message does not indicate anything other than the default value for the 5th parameter.

I mean that when 5th parameter is .T. doesn't affects GetCurrentFolder(). But whatever be this parameter, user can look up searching at any folder, any subfolder.

kcarmody wrote:I just tested it and find that the trailing backslash is not needed -- GetFile goes to the folder you name in the 3rd parameter, whether or not it has a trailing backslash, and the files that is shows match the default filter and any other filter the user selects.

You are absolutly right ! Sorry, yesterday I made up several tests and I was not able to find with full name_file+extension_file. Sorry was my mistake.

Posted: **Sat Dec 20, 2014 3:26 am**

Pablo César wrote:
kcarmody wrote:Windows does not easily allow you to do this. The HMG function GetFile() is basically a shell for the Windows function GetOpenFileName(), which uses the Windows OPENFILENAME structure. This structure does not allow the default folder to be an array, just a scalar value. In order to implement your suggestion, someone would have to write a variant of GetOpenFileName() out of more primitive components. That's a pretty big piece of C programming, and it's not worth it to me.
Thank you for your suggestion,

I didn't suggest anything.

Pablo César wrote:but is not is not feasible.

My whole point what that your suggestion is not feasible, unless you can find someone who wants to rewrite GetOpenFileName().

Pablo César wrote:The strange that I read this:
Screen1.png
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

But I tested in Win7 and when the 3rd parameter is not informed not assume that.

I don't know what you mean by "strange that I read this" or "3rd parameter is not informed not assume that". The text you quote, which is MSDN documentation for the default folder parameter, does not state or imply that this parameter can be an array. That is why your suggestion is not feasible.

Pablo César wrote:
kcarmody wrote:
Pablo César wrote:The user can change this folder, unless you set the 5th parameter, lNoChangeDir.
I thought when 5th parameter i being setted as .F. it was only for positioning folder at returns. (Here to see Claudio's indication)
I don't know what you mean by "positioning folder at returns." The 5th parameter controls whether the user can change the folder from the one you set in the 3rd parameter. Claudio's message does not indicate anything other than the default value for the 5th parameter.
I mean that when 5th parameter is .T. doesn't affects GetCurrentFolder(). But whatever be this parameter, user can look up searching at any folder, any subfolder.

Yes, you are correct! Sorry for the misunderstanding.

Kevin

Posted: **Sat Dec 20, 2014 12:53 pm**

kcarmody wrote:
Pablo César wrote:Thank you for your suggestion,
I didn't suggest anything.

Ok, let's say: thank you for your response.

kcarmody wrote:
Pablo César wrote:but is not is not feasible.
My whole point what that your suggestion is not feasible, unless you can find someone who wants to rewrite GetOpenFileName().

That's what I not want to ! Not for my only need.

kcarmody wrote:
Pablo César wrote:The strange that I read this:

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

But I tested in Win7 and when the 3rd parameter is not informed not assume that.
I don't know what you mean by "strange that I read this" or "3rd parameter is not informed not assume that". The text you quote, which is MSDN documentation for the default folder parameter, does not state or imply that this parameter can be an array.

Strange because something should be work about remarked line. MSDN was not extended to explian how it do this. But as you said, doesn't means that it could be used an array even I understanding that lpstrFile is being created as ARRAY from buffer at C:\hmg.3.3.1\SOURCE\c_dialogs.c in C_GETFILE function. Sorry if I am wrong, but for me lpstrFile is passed as array, doesn't it ? If it is, why MSDN would not use it ? I ask this for myself, of course all is hipothetic and wonderful to have it for better results. It is just a wish Kevin.

I thank you Kevin for your explainations, we learn from each other when we exchange ideas and concepts. Thank for your taking time for these matters, I appreciated.

Posted: **Sat Dec 20, 2014 9:13 pm**

Pablo César wrote:
kcarmody wrote:
Pablo César wrote:The strange that I read this:

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

But I tested in Win7 and when the 3rd parameter is not informed not assume that.
I don't know what you mean by "strange that I read this" or "3rd parameter is not informed not assume that". The text you quote, which is MSDN documentation for the default folder parameter, does not state or imply that this parameter can be an array.
Strange because something should be work about remarked line. MSDN was not extended to explian how it do this. But as you said, doesn't means that it could be used an array even I understanding that lpstrFile is being created as ARRAY from buffer at C:\hmg.3.3.1\SOURCE\c_dialogs.c in C_GETFILE function. Sorry if I am wrong, but for me lpstrFile is passed as array, doesn't it ? If it is, why MSDN would not use it ? I ask this for myself, of course all is hipothetic and wonderful to have it for better results. It is just a wish Kevin.

lpstrFile is not an array but a null-delimited list of path names. This list is converted to a Harbour array if it contains more than one path name.

More technically, lpstrFile is a pointer to a string called buffer. Note the initialization of buffer on line 170:

Code: Select all

   TCHAR buffer    [ _MAXMULTISELECTFILE  *  MAX_PATH ];

This is not an array but just a big string.

I have done some more testing and have found that GetFile does not allow you you to select files from multiple folders. So if lpstrFile contains multiple files, they will all have the same folder name. I think that's why the MSDN documentation does not worry about different path names. Since lpstrFile is a list, the path name will be at the beginning of the list, whether or not there are multiple files.

Pablo César wrote:Thank for your taking time for these matters, I appreciated.

Glad you enjoy.

Kevin

Posted: **Sat Dec 20, 2014 10:12 pm**

Thank you again Kevin for your clarifications about lpstrFile and you are right to say that GetOpenFileName take a top of this list (first element) it what I already supposed to be. This same folder name would it be changable accordingly full path passed from lpstrFile. Probably in the future subject to goodwill of MSDN to implement it. Imagine to choose the each type of file and positioning at the expected folder in each item.

Like this:

: Screen1.png (36.13 KiB) Viewed 6464 times

Once again thank you for your comments and patient.

HMGforum.com

Enhancements to GetFile() and PutFile()

Enhancements to GetFile() and PutFile()

Re: Enhancements to GetFile() and PutFile()

Re: Enhancements to GetFile() and PutFile()

Enhancements to GetFile() and PutFile()

Re: Enhancements to GetFile() and PutFile()

Enhancements to GetFile() and PutFile()

Re: Enhancements to GetFile() and PutFile()

Re: Enhancements to GetFile() and PutFile()

Re: Enhancements to GetFile() and PutFile()

Enhancements to GetFile() and PutFile()