Polling File Walkback Override?

To communicate between two .exe's via file polling, each program needs
to receive an error communication from the OS instead of walking it
back to the user.  Is there an example of either getting a message from
the OS on success or failure of a file open or pre-empting walkback?
For file polling, I need to simply wait until the file actually is
available then operate normally.

Thanks,
Kirk Fraser

I think that the Shell project on dolphin harbour might do what you are
after.

http://www.dolphinharbor.org/dh/projects/shell/index.html

Although - communicating that way is not ideal - there are all kinds of
gotchas with that. Files being left behind, locking problems etc.
Communicating via a socket might be better if you can.

Tim

Thanks for your suggestion.  I looked at the website, downloaded the
demo and packages, and then emailed the authors.  Steve Waring wrote:
"I am not aware of that being part of the Shell packages."

Also, one of the .exe's I'm working with doesn't have sockets
available.

So I am looking for more suggestions.  Perhaps Ian or Andy has
something?

Kirk

Overcomer wrote:
> Thanks for your suggestion.  I looked at the website, downloaded the
> demo and packages, and then emailed the authors.  Steve Waring wrote:
> "I am not aware of that being part of the Shell packages."

I'm pretty sure "Ability to monitor file and folder changes by
registering for Shell Notification events." sound like the thing you
want to achieve. The functionality is wrapped in the "DH Shell
Notifications.pac" package available on dolphinharbor.

CU,

Udo

Overcomer wrote:

 > So I am looking for more suggestions.  Perhaps Ian or Andy has
 > something?

I don't, other than mentioning that Dolphin 6 might have something that
would probably work for you.  The following is from the class comment
for FileSystemChangeReader

=~=~=~=~=~=~
FileSystemChangeReader is a class of objects that can be used to monitor
the file system for changes occurring in a specified directory, and
(optionally) its sub-directories. The directory can reside on the local
computer, a network drive, or a remote computer, as long as the
computers concerned are not running Windows 9x (which does not support
the necessary Win32 API).

FileSystemChangeReader employs the ReadDirectoryChangesW API to request
directory monitoring, and uses Win32 overlapped I/O in conjunction with
asynchronous procedure calls to receive the notifications. By utilising
Dolphin's generic callback mechanism overlapped I/O APCs are simple and
efficient, however because they are received when Dolphin enters an
alertable wait state, they will normally be processed by the idle
process when it issues a MsgWaitForMultipleObjectsEx call to quiesce the
system.

FileSystemChangeReader itself is abstract, and has subclasses that
publish the file system notifications either as Smalltalk events on the
main UI thread (FileSystemWatcher), or by pushing them onto a
SharedQueue for processing by a background thread (FileSystemChangeReader).

To monitor the entire contents of a directory and its sub-directories,
pass the name of the directory with or without a terminating back slash,
for example:
        FileSystemWatcher monitorDirectory: 'c:\temp'

To monitor a specific file set up a monitor on the directory and then
set the filename as the filter, for example:
        fscr := FileSystemChangeReader directory: 'c:\temp'.
        fscr filterString: 'blah.txt'.
        [[| change | change := fscr next. Transcript print: Time now; display:
': '; print: change; cr] repeat] forkAt: Processor userBackgroundPriority.
        fscr startMonitoring.

A range of files matching a wildcarded filename, or filenames, can also
be monitored.
        fsw := FileSystemWatcher directory: 'c:\temp'.
        fsw filterString: '*.txt;*.doc'.
        fsw startMonitoring.

The filters can also be set using the #filters: method and passing an
array of strings as its argument.

The #watchSubDirs flag allows control over whether the watcher will also
monitor for changes in files matching the filter in sub-directories.

It is possible to mask out certain change events (which one might want
to do if monitoring a frequently updated directory), or receive more
detailed changes events (such as changes to file sizes, and even the
time of last access) by setting the #notificationMask. By default a
FileSystemWatcher will report the addition, modification, removal and
renaming of files.

N.B. If you monitor a directory such as c:\Windows\ or :
c:\Windows\System32, you may start to receive so many notifications that
system performance is impacted.  It is advisable to consider carefully
before monitoring any directory.
=~=~=~=~=~=~

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

I have developed my own class to monitor file and directory changes in
Dolphin 5. It was my first attempt at writing Smalltalk code after a
very long abstinence, so it is probably a lot more crude and a lot less
sophisticated than the Dolphin 6 solution. However until the time
Dolphin 6 is released, it might still be useful.

You can download it at:
   http://www.geocities.com/bernhard_kohlhaas/FileSystemMonitoring.zip

and are welcome to use it in your application, whether non-commercial or
commercial.

Usage example:
   DirectoryChangeWatcher
        on: 'C:\'
        withSubtree: true
        monitoringEvents:
                (Array with: #changeFileName with: #changeLastWrite)

Best Regards,
Bernhard


Ian Bartholomew wrote:
> Overcomer wrote:
>
>  > So I am looking for more suggestions.  Perhaps Ian or Andy has
>  > something?
>
> I don't, other than mentioning that Dolphin 6 might have something that
> would probably work for you.  The following is from the class comment
> for FileSystemChangeReader

[...]

Thanks to everyone.  I did not find code in the Shell system I could
use for this task but that may be just my own unfamiliarity with what's
going on.

Today I was inspired to look at File instead of FileStream for a
solution and I think a minor change to the open method (of course
renamed to avoid conflict) will take care of my problem.

I will also look at the D5 monitoring solution by Bernhard which looks
promising.

The futuristic preview by Ian is interesting but right now I need to
prove my Smalltalk.exe can communicate with a VB.exe so I can bootstrap
my new language LogicTalk into existance.

I do now see the power of using Sockets but for now file polling will
do.

Thanks again,
Kirk