mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#261673 09/11/17 03:10 AM
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Calling $sfile and going to the Windows's fonts's folder, it's not allowing me to enter that folder, instead $sfile will return with the value "C:\Windows\Fonts" for example.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. This is because the fonts folder is a special folder that redirects any attempt to open it to the Font control panel. That said, there should be a way to make mIRC return an error in this case. This change should be in the next version.

Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I see, we more or less figured it was a special folder but there was some differences with others functions, like $findfile is able to report the fonts in the folder, $isdir works etc, so I was thinking maybe it could be made to work.

On a side note, $sfile and $sdir are already hidding some folders, (try them on the Windows folder and compare with what you see in the explorer), I think it would be better for mIRC to hide that font folder; I believe returning an error and halting the script is going to cause some issues in some scripts, because I don't think it could have been anticipated that $sfile/$sdir could halt with an error once the dialog is displayed, what do you think?


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
The $sfile and $sdir dialogs are Windows managed dialogs, so mIRC cannot selectively hide files/folders in that folder. If displaying an error is not useful, I can leave it as it is currently.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Khaled
The $sfile and $sdir dialogs are Windows managed dialogs, so mIRC cannot selectively hide files/folders in that folder. If displaying an error is not useful, I can leave it as it is currently.


IMO it would be better to return $null than raise an error or return something incorrect - as scripts can then check this easily rather than have to deal with it using :error etc.

Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I see. Then what about making them returns the plain text $error value which is used in some cases in mIRC, because scripts already check for $null value and they all (from my own experience) assume the user canceled the dialog, which is a fair assumption imo, not sure if $sfile/$sdir could return $null to mean anything different in the past.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Wims
What about making them returns the plain text $error value which is used in some cases in mIRC, because scripts already check for $null value and they all (from my own experience) assume the user canceled the dialog, which is a fair assumption imo, not sure if $sfile/$sdir could return $null to mean anything different in the past.


$error documentation suggests it is only filled when a formal error is raised and you go to :error and is reset by /reseterror. That does not mean that we should not use $error, just that we have to be careful that this won't break scripts that check whether $error is $null later on. IMO if we are going to use $error, then we should do it properly and raise the error and look for :error. So long as this is documented, then the script writer can handle it in the alias they use for $sdir $sfile or move their code into a separate alias in order to achieve this - and we can document this in WikiChip.

But this is still more complex than returning a special value. If $null is already used (when cancelling the dialog) how about returning $false instead?

Last edited by Protopia; 14/11/17 10:30 AM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
It turns out that the Windows file dialog does not treat this as an error. It returns a successful result with no errors set. One way around this would be to make the dialog itself display an error, however this would require unsetting the OFN_NOTESTFILECREATE flag, which mIRC has used for a long time because there were side-effects without it. So the only remaining option is for mIRC to check if the result of $sfile() is an existing folder. If it is, it will make $sfile() return no value. This will be in the next version.

Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I specifically mentioned the plain text $error value.
$error is an identifier filled when you use the goto :error but it is also a plain text value returned by some identifiers, $dde for example (I think there are some others but can't find them right now).
Using $false is the same idea as using plain text $error, but plain text $error makes more sense, nothing is false here.

Last edited by Wims; 14/11/17 10:51 AM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Quote:
If it is, it will make $sfile() return no value. This will be in the next version.
But that makes it impossible for a script to tell the difference between the user canceling the dialog and the folder being a special folder, what do you think of using plain text $error instead, to allow scripts to tell the difference?


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Wims
I specifically mentioned the plain text $error value.
$error is an identifier filled when you use the goto :error but it is also a plain text value returned by some identifiers, $dde for example (I think there are some others but can't find them right now).
Using $false is the same idea as using plain text $error, but plain text $error makes more sense, nothing is false here.

Using plain text which looks like an identifier is (IMO) a bad idea for several reasons.

1. If you code this as you might naturally do, then it won't work:
Code:
if ($sfile(C:\) == $error) return

To make it work you have to code:
Code:
if ($sfile(C:\) == $ $+ error) return


2. "$error" is a valid file name. So if I select such a file in $sfile dialog how do you distinguish between the two?

For $sfile (or any identifier returning a file name) you would have to use text which is impossible to be a valid filename. According to Microsoft, the following characters are not valid in a filename: *?"<>|

How about using ? followed by an explanatory error message (either generated by Windows or mIRC)?

Last edited by Protopia; 14/11/17 12:21 PM.
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Quote:
Using plain text which looks like an identifier is (IMO) a bad idea for several reasons.
I agree that there isn't much difference between returning a static "$error" vs "error"; and since the former might be confused as an identifier it shouldn't have been used, but $!error can be used instead of $+, it's simple enough and working, which is what matters to me.
Quote:

2. "$error" is a valid file name. So if I select such a file in $sfile dialog how do you distinguish between the two?
If you select such a file the complete filename will be returned, I don't think $sfile can possibly returns "$error" for a valid filename, it would be 'C:\$error' or something.

Reading versions.txt about $inwho it looks like Khaled wants to move away from using such returned values, but there is a need for script to tell if the $sfile call returns because of a special folder or if it's because the user pressed the escape key, for example. edit: well that note about $inwho was for mIRC 6.0 and $chan().ial still return $inwho although it says that future version would stop doing so.

Last edited by Wims; 14/11/17 12:38 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted By: Wims
$!error can be used instead of $+, it's simple enough and working, which is what matters to me.
Still not intuitive.

Originally Posted By: Wims
If you select a file $error, the complete filename will be returned (e.g. C:\$error). I don't think $sfile can possibly returns "$error" for a valid filename.
True. I have tried to think of a counter example, but cannot create one.

If $sfile returns "$error" then, since this is the only way it can start with $, I would personally test for this with:
Code:
var %f $sfile(C:\)
if ($left(%f,1) == $) return

Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I'm afraid I have to ask again, are you not concerned with the fact that scripts already use $null value from $sfile to indicate that the user canceled the selection dialog?
Right now a $null value returned from $sfile because of 'reserved' folder is going to be taken as a cancel, and rightfully so.
In others words, there is no way to tell the difference between the user canceling with the mouse/keyboard and the folder being a reserved folder.
Not only it's breaking backward compatibilities but the behavior itself doesn't help us because we can't even tell either that a reserved folder was reached (regardless of users's canceling).
Please consider returning plain text $error or any other similar value that would indicate a reserved folder was reached, or at least please explain the reasoning of this choice.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
What about returning $false - this is not the same as $null so you can test it explicitly and will be returned by any other situation.

Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
We already discussed the value that could be returned, I said that it is meaningless as long as functionality is there.
It could return the value "468737", "sup?", "-1", "reserved" "$error" or "$false", as long as it's not a valid value currently returned by $sfile.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I'm posting a reply because you didn't answer me but, this change of $sfile returning $null on reserved folder will break my scripts (and it should break all scripts which handle $null as a 'cancel' which is common since we have no way of knowing when the user canceled the dialog), it doesn't look like there is a need for this break of backward compatibility at all, where returning a different value such as -1 would be a much better idea.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
As far as I can tell, returning anything other than a filename or $null would break backwards compatibility because these are the only values that $sfile() has ever returned. Every script that uses $sfile() and checks if it returns $null would be broken if it returned -1.

Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Ahah, yes, that's how backward compatibility works sorry, my own scripts would break on -1 if not modified but since I'd be modifying them, I forgot.

Then a solution would be to improve $sfile to allow it to return a different value when the dialog is canceled.

Something like $sfile().cancel, which would return -1 if the old $sfile were to return $null (which as far as I know, is only possible when the user cancel the dialog), and would still return $null for reserved folder


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I have added a $sfstate identifier that is usable immediately after $sfile() and returns "cancel", "error", or $null. This will be in the next version.

Page 1 of 2 1 2

Link Copied to Clipboard