Welcome, Guest. Please login or register.

Author Topic: ACTION_FINDOUTPUT packet's lock in dp_Arg2 must be shared ?  (Read 1188 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline JoseTopic starter

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2869
    • Show only replies by Jose
ACTION_FINDOUTPUT packet's lock in dp_Arg2 must be shared ?
« on: March 13, 2006, 07:51:22 PM »
The docs don't mention it so I assume it can be shared as it's only used as a reference to the directory where the file will be created right ?

[EDIT] Yeah, I know I can use a full path in dp_Arg3 but I prefer it this way given what I already have.

Cheers:pint:
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Thomas

Re: ACTION_FINDOUTPUT packet's lock in dp_Arg2 must be shared ?
« Reply #1 on: March 13, 2006, 08:52:28 PM »

Erm, why don't you just use Open ? For asynchronous I/O you only need to detach Read and Write. An asynchronous Open or Close does not make any sense IMHO.

BTW, did you see my example in your previous thread ?

Bye,
Thomas

Offline JoseTopic starter

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2869
    • Show only replies by Jose
Re: ACTION_FINDOUTPUT packet's lock in dp_Arg2 must be shared ?
« Reply #2 on: March 13, 2006, 09:02:11 PM »
"BTW, did you see my example in your previous thread ?"

Only now. I'm not here as often as I used to be. Meanwhile I've already read most necessary stuff on the DevCD regarding packets. It seems easy.

BTW, the reason a lock on a directory is usefull to me is that the code I've already written allows for global default directories to be defined for various types of stuff. By using a lock on the path for those directories, as the FINDOUTPUT packet does, I wouldn't have have the hassle of creating a new path string to include the name of the file, for every new file I want to create. I remember there are dos functions to deal with path strings but been long since I read about that, and using that would create less efficient code anyway, let alone the time spent on checking how to deal with those functions again.
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Thomas

Re: ACTION_FINDOUTPUT packet's lock in dp_Arg2 must be shared ?
« Reply #3 on: March 14, 2006, 07:37:37 AM »

Quote
I wouldn't have have the hassle of creating a new path string to include the name of the file, for every new file I want to create.


You can do

oldcd = CurrentDir(lock);
fhandle = Open(filename,MODE_xy);
CurrentDir (oldcd);

in order to open a file relatively to a lock.

Quote
BTW, the reason a lock on a directory is usefull to me is that the code I've already written allows for global default directories to be defined for various types of stuff.


Did you read all the requirements of the FINDOUTPUT packet ?

For example if your global directory points to Work:Files but the user entered an absolute path like Sys:Prefs into the settings window, you have to make sure that the lock for FINDOUTPUT points to Sys: instead of Work:Files. You cannot just use the global lock.

Bye,
Thomas

Offline JoseTopic starter

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2869
    • Show only replies by Jose
Re: ACTION_FINDOUTPUT packet's lock in dp_Arg2 must be shared ?
« Reply #4 on: March 21, 2006, 04:55:47 PM »
"Did you read all the requirements of the FINDOUTPUT packet ?

For example if your global directory points to Work:Files but the user entered an absolute path like Sys:Prefs into the settings window, you have to make sure that the lock for FINDOUTPUT points to Sys: instead of Work:Files. You cannot just use the global lock."


Don't remember reading that, thanks for pointing it out...
\\"We made Amiga, they {bleep}ed it up\\"