[AccessD] DirWatcher - was RE: Cool stuff - was RE: using a dtsx in .Net

Just wondering, if you used this method to register the com class dll.
It uses regasm and gacutil to remove any previously named dll
and reinstalls in the registry.
See :
http://samples.gotdotnet.com/quickstart/howto/doc/Interop/Building_Samples_COM2NET.aspx

the install batch file looks like this for your dll FX20Wrapper.dll

regasm 
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\system.windows.forms.dll"

gacutil -u FX20Wrapper
regasm /u "VB2005\FX20Wrapper\bin\Release\FX20Wrapper.dll"

regasm /tlb "VB2005\FX20Wrapper\bin\Release\FX20Wrapper.dll"
gacutil -i "VB2005\FX20Wrapper\bin\Release\FX20Wrapper.dll"

To use Access set a reference to the tlb file that will be in a
directory like below depending on where you installed the project.
\VB2005\FX20Wrapper\bin\Release\FX20Wrapper.tlb

The tlb will allow Access to see the class definitions and do a compile.

JWColby wrote:

>Just an FYI, the dirwatcher com object from the webcast apparently can be
>used "simultaneously" from Access.  I created a form with two text controls.
>Each text control creates an instance of the referenced com object and
>passes in whatever you type in as a directory.  If you pass in an invalid
>dir name it errors, else it watches.  I then created two empty directories
>and tested by creating new text files in each directory.  The correct events
>fired and I was notified of the appearance of a file (and it's name) in the
>correct watched directory.  
>
>And of course this does require a completely external "watcher widget" which
>has to be registered etc., at least for use in Access.
>
>WARNING... The COM object DELETES the file behind itself so it is NOT
>appropriate for use "as is", nor did I expect it to be, but it does function
>inside of VBA and it can do so multi-instanced.
>
>The following is the code in the test form that I created:
>
>Option Compare Database
>Option Explicit
>
>Dim WithEvents fDirWatcher1 As DropDirMonitor.DirWatcher
>Dim WithEvents fDirWatcher2 As DropDirMonitor.DirWatcher
>
>Private Sub fDirWatcher1_ProcessingFile(ByVal FileName As String)
>    MsgBox "Watcher 1 fired: " & FileName
>End Sub
>
>Private Sub fDirWatcher2_ProcessingFile(ByVal FileName As String)
>    MsgBox "watcher 2 fired: " & FileName
>End Sub
>
>Private Sub Form_Close()
>    Set fDirWatcher1 = Nothing
>    Set fDirWatcher2 = Nothing
>End Sub
>
>Private Sub Text0_AfterUpdate()
>    Set fDirWatcher1 = New DropDirMonitor.DirWatcher
>    fDirWatcher1.Init Text0.Value
>End Sub
>
>Private Sub Text2_AfterUpdate()
>    Set fDirWatcher2 = New DropDirMonitor.DirWatcher
>    fDirWatcher2.Init Text2.Value
>End Sub
>
>John W. Colby
>Colby Consulting
>www.ColbyConsulting.com
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby
>Sent: Saturday, April 21, 2007 3:38 PM
>To: 'Access Developers discussion and problem solving'
>Subject: Re: [AccessD] Cool stuff - was RE: using a dtsx in .Net
>
>Thanks for that.  I just checked out this solution and while it does
>function, it appears to have some serious limitations, specifically that it
>can only monitor one directory, and apparently that it can pretty much do
>nothing else.  The reason is that VBA is single threaded, and this code is a
>tight loop with a DoEvents to allow the appearance of normalcy.  However it
>really doesn't allow anything else to function.  I tried to make this a
>class so that I could then do two (or more) instances.  The first instance
>starts up but the second instance is not allowed to instantiate, with a "the
>macro or validation rule prevents..." error thrown in the event of the text
>box that tries to set up the second instance.  In essence it appears that
>this would work just fine in limited situations where you just want an
>application to monitor a directory, do something specific, then go right
>back to the monitor loop, however it may completely prevent a broader
>application from functioning after the loop is started.
>
>One of the things I am trying to do is to start slowly doing some VB.Net
>development.  I have a handful of things that really don't "fit" Access as a
>development tool, e.g. running things as services.  I am also doing a lot
>more stuff directly out in SQL Server 2005, and I want the ability to run a
>powerful programming language that more directly talks to SQL Server, and
>also does not require a copy of Access installed in order to operate.
>VB.Net will give me that if I can ever get it figured out (I just need the
>TIME!).  
>
>The .Net code basically listens for EVENTS from a DotNet DiskWatcher object.
>I haven't gotten so far as to determine whether when wrapped as a COM object
>it can be used more than once from inside of Access.  The Web Seminar left
>out the critical (written) instructions for compiling and registering the
>com object, though the instructions are in the video, so I am headed back to
>watch that portion of the video again.
>
>John W. Colby
>Colby Consulting
>www.ColbyConsulting.com
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada