Thanks Xavier I've got some more questions
> HKLM (the regedit abbrev) is only local to your machine but changing the
> other keys will not affect the network! Rather, it's the network
> system that
> will change your keys.
Do you mean that the network file classes get forced into the workstation
while loged on? Does this or could this cause files with the custom key to
not appear in the ask file dialog when the filter is set to the custom key?
>
> If you want a special file association spread out, you'll have to
> include it
> into the login script to add the missing key. Ask your domain admin or
> consult www.ntfaq.com.
I don't need this infact this i just need files to be associated on the
machine that my program is installed on. This has worked at all times with
the exception of the NT laptop when logged on.
>
> Another solution would be to write it when your program runs BUT, if the
> user is not admin of his workstation or the policy forbids the users to
> change their registries (which it should), then it's back to the login
> script.
If this is a common policy then the program may not be able to support
networked computers. It does seem odd though because quite a few common
programs use the registry for storage like user preferences and recent docs.
I would think that these softs would completely fall down under a situation
like this.
>
> Concerning the slashes and quotes and command
>
> use this script in your startup (unless it's for Macs of course) (please
> correct if im wrong but it works between NT and 95x.
>
> on CheckShellPlatform
> if (the platform = "win32") and (word 1 of the systemversion is
> "windows")
> then
> set the shellcommand to "command.com"
> else
> set the shellcommand to "cmd.exe"
> end if
> end CheckShellPlatform
cmd.exe is for NT then is it? Is command.com not reliable on NT or is
cmd.exe just better? Would this cause files not to be seen or the program to
freeze when cloning stacks from a data folder but all only when the computer
is logged on and fine the rest of the time?
>
> and if there is a space in a name in an NTFS volume you'll have to enclose
> the string in quotes like this. I dont remember having problems with the /
> or \.
>
> Normally, this does the job:
> get "dir c:\"
>
> But here, there is a folder/shared folder with a space in it:
>
> get "dir" && quote & "\\server\share test" & quote
> get shell(it)
>
I dont use this I guess it's equivalent to
set the directory to blah
get the files
Is the way you describe more stable? I guess the problem is I've never had
the opportunity to muck around on a network so I'm a bit concerned that I'm
going to have to say "sorry can't fix your problem, don't know how" to my
clients.
Thanks again Xavier all help is welcome and appreciated
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
