A TG007 community discussion started by Warrior124.
Just thought I'd mention that the $findfile there literally does nothing. $findfile($mircdir,hos.dll,1) will ALWAYS be $mircdirhos.dll.
why not this 
alias hos {
var %f = $shortfn($$findfile($mircdir,hos.dll,1))
if ($isid) return %f
else dll %f $1-
}
and this 
hos SetWinTheme $dialog($dname).hwnd off <dialog id/'s here>
I hope this is much more easier .
There is nothing so absurd but some philosopher has said it
Just thought I'd mention that the $findfile there literally does nothing. $findfile($mircdir,hos.dll,1) will ALWAYS be $mircdirhos.dll.
Not true. $mircdir refers to the main directory. However, $findfile($mircdir finds the file being searched for in both the main directory, and also the sub-directories as well. Otherwise $findfile is a useless command.
$findfile(dir,wildcard,N,depth,@window | command)
Searches the specified directory and its subdirectories for the Nth filename matching the wildcard file specification and returns the full path and filename if it is found.
Properties: shortfn
$findfile(c:\mirc,*.exe,1) returns c:\mirc\mirc.exe
If you specify a custom @window name (with a listbox) instead of the N parameter, mIRC will fill the custom @window listbox with the results.
If you specify a command, the command is performed on every filename that is found. You can use $1- to refer to the filename, eg. //echo 1 $findfile($mircdir,*.*,0,echo $1-)
If you use /halt in the command/alias, this halts the search.
If you specify a depth, mIRC will only search N directories deep for matching filenames.
You can specify multiple wildcards by separating them with semi-colons, eg. *.exe;*.txt;*.hlp.
The $findfilen identifier returns the Nth position of file that was found.
Note: Both the depth and @window/command parameters are optional.
Well yeah, I guess so, but the point still stands that you'll be better off hardcoding the path.
I go with hixy ,warrior your coding is hard and its not sleek .
There is nothing so absurd but some philosopher has said it
lol, so we're going to get into who has the best coding? I suppose there are better ways to code, and such, and I never claimed that the code I provided was the "only" way to code it. I was just providing an example, and yes. Hardcoding is always better, and much faster. However, lets face it. People don't keep the same files in the same directories. That is why a huge percentage of addons don't work, and that is why I provided the code in my coding to search for the dlls, and again. It was just an example coding. Not something you neccessarily have to do.
I don't think idiot proofing your script is worth the speed decrease that users with half a brain will suffer from
Well, ask yourself this. Would you wnat an addon that doesn't work, because you didn't know you had a dll in the wrong folder, or would you want something that works? Like I said. There are better ways to code. However, what I gave was just an example. If you don't like it you don't have to use it. If you know how to make your own script then it is always best to do so. that way whoever does has a script they can suit to their needs, and wants.
P.S.: By the way, this post isn't about who can make the better script. It was about getting help for a problem. Which by the way no one seemingly was able to help me out with, and I found the solution on my own. So, please keep the remarks to yourself.
Also, unless the script one uses is like one of the biggest scripts in the world with so many files in there it is like counting stars, $findfile doesn't slow the script down enough to be that much of a trouble. Crytons code is terrific, and I suggest anyone to use it. However, don't knock someone elses coding. Especially if one has found a way when no one else was seemingly able to, and decides to share what he/she has found to help others. If you have a better way to code, then do like Cryton did, and volunteer it if you wish, but don't knock others for finding solutions when you didn't.
All I'm saying is that randomly moving files around in a program/script install directory is asking for trouble. If it breaks, that's the fault and problem of the user that moved said files around, not the author of the script that would work if it was left as it was.
I think that users should be able to move the *entire* script to a different directory (eg: c:\coolscript\ to c:\program files\coolscript\) but not move files within the script directory to a different directory (eg: c:\coolscript\dlls\mdx.dll to c:\coolscript\mdx.dll).
Also, this isn't a pissing contest, I'm just trying to help.
I apologize hixxy, and yes you are right. It is the fault of the user if they do that. However, I like for my scripts\addons to work reguardless of what the user does, lol. When I first started scripting I would hard code, myself because I knew it was faster. However, I'd get complaints about how my scripts/addons wouldn't work, because it wasn't finding some files\dlls. That is why I started using $shortfn($findfile. Yes, it does slow things down some, but at least I know it will work even for people who does move things around. I agree with you. Hard coding is alot better, and I suggest people don't move files around, or whatever.
On an unrelated topic but hos.dll nonetheless, is it just me or does it take 10+ seconds for other people's docked dialogs on start? I'm just using to remove the XP theme from status bars but it hardly seems worth it given the load time.
Get the Tech outta here!
I've been reading the comments on this post from hixxy and warrior124. $shortfn and $findfile do not slow things down so much that you shouldn't use them. Of course just putting hos.dll in the main directory and calling it just by using "dll hos.dll" would be faster, but using the other aliases do not slow things down so much to where you even notice a different. I understand Warrior's comments though. You guys were talking about if people moved files around that would be there fault. But that's not the point he was making. If he decided to release an addon and user already had a dll the addon used and decided not to extract it, it would still work because the script would search for it. I always believe in stability over performance. I'd rather see in that scripts/addons rather than speed. That's just my opinion though. I script things the exact same way.
Sign in to reply or start a new topic where your account has permission.