Brian, with our Pmail network installation unfortunately we are the minority [:S], means for the majority of the Pmail single installations the discovery of the user mailbox directory via Registry Key should work.
I've checked some different machines here and found some machines with that RegKey and some without. I remember that sometimes I've firstly made a local installation of Pmail to make "Pmail" available in the Windows list of standard applications for mail (mailto: / sendto:). But in the meantime I only add a link to the server share where wsendto.exe resides within Firefox and additionally within folder C:\Users\<user>\AppData\Roaming\Microsoft\Windows\SendTo\. That's why the availability of a RegKey to the user mailbox directory is not ensured in general.
In general I'm with Brian and would prefer the dropping of work and report files into user's mailbox directory. And for our minority shared network installation, we (Administrators) could manually check/adapt the path to user's mailboxes within pmical.ini subsequently, in case PMICAL neither found a local mailbox directory nor RegKey. But this would lead to only 1 mailbox directory path within the central pmical.ini! We've got up to 20 user mailboxes here. I think it doesn't work.
Further, here with us, we could start Pmail with different local users from each machine, means PMICAL should have to discover the choosen user (from Pmail) when it will be called by an incoming invitation mail. Don't know whether this is practical.
I think it's really the better way to avoid keeping of work and report files. From my point of view this is not really necessary. If I need such a work/report file again, I have simply to open the invitation mail again. And in this case we could still use %temp% for that files and directly delete them after closing the PMICAL window or invitation mail. There would be only one issue remaining (sorry for that Martin): In our great network installation [:D] we are also able to simultaneously open two Pmail instances, where each of them are connected to another user (means user mailbox). And in the rare case that both inboxes contain invitation mails, PMICAL would create its work files at %temp% for both users simultaneously as well. Maybe this could lead to conflicts.
ps:
Martin, I've received your mail with pmicalhelp.htm. It would be a pleasure for me to check it but at the moment I would wait until the final working directories and connected stuff are settled. Is this ok?
<p>Brian, with our Pmail network installation unfortunately we are the minority [:S], means for the majority of the Pmail single installations the discovery of the user mailbox directory via Registry Key should work.</p><p>I've checked some different machines here and found some machines with that RegKey and some without. I remember that sometimes I've firstly made a local installation of Pmail to make "Pmail" available in the Windows list of standard applications for mail (mailto: / sendto:). But in the meantime I only add a link to the server share where wsendto.exe resides within Firefox and additionally within folder C:\Users\&lt;user&gt;\AppData\Roaming\Microsoft\Windows\SendTo\. That's why the availability of a RegKey to the user mailbox directory is not ensured in general.</p><p>In general I'm with Brian and would prefer the dropping of work and report files into user's mailbox directory. And for our minority shared network installation, we (Administrators) could manually check/adapt the path to user's mailboxes within pmical.ini subsequently, in case PMICAL neither found a local mailbox directory nor RegKey. But this would lead to only 1 mailbox directory path within the central pmical.ini! We've got up to 20 user mailboxes here. I think it doesn't work.
</p><p> Further, here with us, we could start Pmail with different local users from each machine, means PMICAL should have to discover the choosen user (from Pmail) when it will be called by an incoming invitation mail. Don't know whether this is practical.</p><p>I think it's really the better way to avoid keeping of work and report files. From my point of view this is not really necessary. If I need such a work/report file again, I have simply to open the invitation mail again. And in this case we could still use %temp% for that files and directly delete them after closing the PMICAL window or invitation mail. There would be only one issue remaining (sorry for that Martin): In our great network installation [:D] we are also able to simultaneously open two Pmail instances, where each of them are connected to another user (means user mailbox). And in the rare case that both inboxes contain invitation mails, PMICAL would create its work files at %temp% for both users simultaneously as well. Maybe this could lead to conflicts.</p><p>ps: </p><p>Martin, I've received your mail with pmicalhelp.htm. It would be a pleasure for me to check it but at the moment I would wait until the final working directories and connected stuff are settled. Is this ok?
</p>