notification on FileZilla events

[swdld]

Hi,

I read several feature requests about processing shell commands or execution of external processes after FileZilla Server executed something finally. I need that too...

Beeing a programmer too, I understand your need to keep your code clean, ...but please read more - some lines could possibly help.

You stated in this forum, that triggering some external process/ shell command, in your opinion needs a prior implemented hash functionality to check the transfers' integrity.
You are right as long as you think of "serious" transfers with a high importance. But think of millions of transfers, which all are for pleasure only. If a download is broken (negative integrity check), no one would care anyway.

So my suggestion: Implement user defined WMessages on specific FileZilla Server functions. Any FileZilla admin could use them on his own risk (because there are situations with no risk) and you needn't care about what action to trigger which way!

It could go like this: FZ Server raises documented user defined WMessages (on Win platforms) after specific actions. Anyone might code his own tool to catch and react on the system events and may start what ever he likes. E.g. I then could code (and make the sources availlable to the public) a tiny VB tool within any interested admin might insert his own shell command for each user defined WMessage you implemented in FileZilla.

If you like, I could code a tiny sample and mail you the sources to think about...
For you it needn't to be much more then some lines with no risk.

To give another example: I coded a sms application which is sending sms'es to dedicated mobile phones with specific text messages. If you would implement to raise a user defined WMessage in the very moment of a crash of FileZilla, any admin could become informed on his mobile phone within half a second.
Thinking of a professional environment, this in some situations might become a very interesting feature of FileZilla!

Cheers, swdld

[botg]

I agree, some notifications would be nice. Quality patches welcome!

To give another example: I coded a sms application which is sending sms'es to dedicated mobile phones with specific text messages.

You send short messages services? Or are are you sending short messages using the short message service?

Correct usage is "I am sending you a SM.".

[swdld]

With "sms" I intended to be understood like that:
http://dict.leo.org/ende?lp=ende&lang=d ... search=sms

What I mean is that I plug in a MOTOROLA USB device with a valid SIM card inserted into my server, prepare the correct settings for my software and then I'm able to send SMS messages to any mobile phone in the world. The MOTOROLA device is fast and it takes about 0.5 secs to send a SMS text message. I may set up a message manually, or driven by code.
By now, I run an internet service which is sending order states to customers automaticly. And too, if a severe problem occours on the service app, the service app triggers the SMS-messaging app to send me an sms (error code included) before the service app terminates (and is started again...).
It works quite well and reliable.

My business application (service) uses FZ Server too and therefore it would be interesting to trigger a user defined WMessage from FZ Server in Win before FZ Server would go down. (But in fact FZ Server runs stable by now!)

On the other hand some people tried to fool me by using uggly FTP-functions (e.g. created subfolders with 10 leading blanc spaces in the folder name so that Explorer displayed them but Win refused to delete them - grrr), and FZ Server has no possibilities to switch off the "MKD"/"XMKD". I'd accept as a workaround to trigger the messaged event from FZ Server that a directory was created (as long as WMessages would become implemented) for checking the folder struckture by code and - just in case - automatical deletion of the directory before any file would be written to it (performed not by FZ Server, but by an external app).
By now, worst case, I must stop the net, format(!) the drive and recover the files. And up today I did not figure out anything faster and more reliable (okay, my SSD drives are fast, but you surely aggree, that this is no brilliant process!)
Getting a FZ Server properties page on which I could (un)check some functions for ignorance would be best, but it's worth to try a workaround to kill the folder before a file gets into it...

---------------------

And I'll be back with some code sample for user defined WMessages on Win platforms and their helpful usage..

Cheers, swdld

PS.: What's your mother tongue?

[botg]

On the other hand some people tried to fool me by using uggly FTP-functions (e.g. created subfolders with 10 leading blanc spaces in the folder name so that Explorer displayed them but Win refused to delete them - grrr)

That's a bug in Windows unfortunately

PS.: What's your mother tongue?

German.

[boco]

By now, worst case, I must stop the net, format(!) the drive and recover the files. And up today I did not figure out anything faster and more reliable (okay, my SSD drives are fast, but you surely aggree, that this is no brilliant process!)

My Explorer deletes such directories. Note that the command line can handle more unusual characters in names. For extreme cases, there's the \\?\ syntax to access the filesystem directly.

Example:

Code: Select all

rd /s "\\?\c:\                       bad folder"

[swdld]

This is my suggestion on how to enable FileZilla (on Windows platforms) to signaling that an event happened (e.g. after a new file was successfully written to the local file system). I added the source code for making it more easy for everyone to implement both sides of the communnication.

Download my sample code, install the both apps on a test drive and launch both, the "FZ-Simulator" and the "WatchDog" for demonstration:
- Double click on one of the selectable sample events from the FZ-Simulator form
- Cause the app to raise a "Windows User Defined Message" by clicking on the button at the lower right corner of the form
Immediately you will recognize a new line in the other app's list. This other app I called the WatchDog or Tracker. It does nothing else than waiting on a "User Defined Windows Message". And as soon as Tracker catches one, it is analyzing the message and processing the previously determined code lines.

Basicly it is needed, that both apps (while they get launched) register in Windows system all user def. WMessages by using the identical strings. The WMessage fireing app 'FZ-Simulator' is fireing with each button click, not careing if any other app is listening. The WatchDog 'Tracker' is waiting for a message, not careing if any app is launched, that may fire something.
Therefore the implementation is quite fail safe, because both apps do not interact directly. They both interact with the system only. All what is needed are the Windows API functions for registering user defined messages. Into the WatchDog 'Tracker' I implemented a CallBack.

Some more advice are included in the zip file I added (both apps with their install routines, Visual Basic 6.0 sources, some small documentation).

Because the system handles the messaging, no restrictions remain on the question of the development platforms. You may implement FileZilla in C (is it?), and the WatchDog in Visual Basic, or the one in Delphi and the other in Java. You are absolutely free on the developing platforms.

If you implement WMessages, I could code a configurable WatchDog (open source). E.g. any user might insert a string into a path TextBox for each event implemented. Every time an event is triggered, a configured command line may be processed.
(Or another way of raising actions upon events may become implemented).


Cheers, swdld

PS:
- Thanks boco for your suggestion on how to delete folders with 'ugly' names ! I'll play around with it...
- The bundle (two install packages, sources and docu is '5.619.192 Bytes' overall, but only 2MB is granted to upload.
What should I do?

[botg]

Source would be enough for me. Better yet, a unified context diff.

[swdld]

context diff.

hugh? What's that?

[boco]

http://en.wikipedia.org/wiki/Unified_diff

[swdld]

Because neither me nor you sent some code, "diff" makes no sense.
Anyway, you may google for getting to know how to implement.
Besides of the CallBack it's beginners stuff anyway.

[swdld]

too, I gave suggestions on how to go further, implementing useful tools for the interested users of the server.
Adding the plain lines seems not enouth to tell, because if you didn't know by now, the code lines wouldn'd tell why to code this way.

[boco]

If you leave the compiled versions out, is it small enough, then?

[swdld]

is it small enough, then?

Explained in post '2012-03-16 13:04', compiled sample apps (that implemented WMessages) are '5.619.192 Bytes' in total.

[swdld]

Für das systemweit gültige Registrieren einheitlicher WMessages ist der einheitliche String in der Win API 'RegisterWindowMessage' essentiell.
Hier wird der 2-n-dimensionale Array 'MxAllWMessages' benutzt um die Strings spezieller Ereignisse (deren Bezeichner) mit den ihnen vom System zugeordneten Long-Werten zu speichern. Im 'MxAllWMessages(0, i)' stecken die Namen der user defined Ereignisse/ der WMessages, jeweils die vom System zugeordneten Longs sind dann im 'MxAllWMessages(1, i)' zugeordnet.
Ist ein Ereignis zu senden, so weiß die sendende App sowieso, welchen Long sie senden will.
Wird das Ereignis anschließend vom Tracker aufgefangen, so wird tatsächlich ein Long aufgefangen, wobei sich aus der gespeicherten Zuordnung das Ereignis ergibt: Wird der Array durchlaufen und der Long der aufgefangenen Message mit allen Elementen in 'MxAllWMessages(1, i)' verglichen, gibt der Match der auffangenden Anwendung Auskunft über das Ereignis der sendenden Anwendung.



Folgendes Modul registriert unter Visual Basic die implementierten WMessages. Identisch müssen die Strings sein in 'MxAllWMessages(0, i)', dann werden es bei Registrierung auch immer die Longs in 'MxAllWMessages(1, i)'. Das gewährleistet die Win API.
Es müssen sich die Entwickler der sendenden und der auffangenden Anwendungen also lediglich(!) über die Strings abstimmen, die mit API-Funktion 'RegisterWindowMessage' registriert werden!
Sub 'sysWMessagesRegister' muß daher so oder ähnlich in allen Prozessen umgesetzt sein, die sich gegenseitig über diese Ereignisse benachrichtigen wollen.



#######################################################################################################################

Code: Select all

Option Explicit
Option Base 0
Option Private Module

'This module registers WMessage handlers (long) for triggering the other apps events.
'Generate unique message numbers for user defined messages (RetVal from teh windows function 'RegisterWindowMessage')

Private Declare Function RegisterWindowMessage& Lib "User32" Alias "RegisterWindowMessageA" (ByVal lpString As String)


Sub sysWMessagesRegister()
   On Error GoTo ErrorHandling
   
   
   'ReDim for resetting array of User Defined Windows Messages:
   ReDim MxAllWMessages(1, 60)                     'Reset array
   
   'Array MxAllWMessages:
   ' <NameOfEvent0>    <Returned Event# from windows for this event name>
   ' <NameOfEvent1>    <Returned Event# from windows for this event name>
   ' <NameOfEvent2>    <Returned Event# from windows for this event name>
   ' <NameOfEvent3>    <Returned Event# from windows for this event name>
   'Note: The names of events you may call as you like, but the strings only must be unique.
   '      The message number, referring a unique event to become triggered later, will be given back from windows as the RetVal
   '      from the function 'RegisterWindowMessage'.
   '      Storing event name and the event number in an array, we later may catch an event number in an external app and, by looping
   '      through the array within that external app, we can determine which one was the referring event. In other words, what event
   '      happened in FileZilla.
   '
   MxAllWMessages(0, 1) = "FZ_IPC_FTP_CMD_DONE_ABOR": MxAllWMessages(1, 1) = RegisterWindowMessage(MxAllWMessages(0, 1))
   
   
   '   ...   Implement some more FTP commands here   ...
   
   
   MxAllWMessages(0, 23) = "FZ_IPC_FTP_CMD_DONE_MKD": MxAllWMessages(1, 23) = RegisterWindowMessage(MxAllWMessages(0, 23))
   
   
   '   ...   Implement some more FTP commands here   ...
   
   
   MxAllWMessages(0, 47) = "FZ_IPC_FTP_CMD_DONE_STOR": MxAllWMessages(1, 47) = RegisterWindowMessage(MxAllWMessages(0, 47))
   MxAllWMessages(0, 48) = "FZ_IPC_FTP_CMD_DONE_STOU": MxAllWMessages(1, 48) = RegisterWindowMessage(MxAllWMessages(0, 48))
   
   
   '   ...   Implement some more FTP commands here   ...
   
   
   MxAllWMessages(0, 50) = "FZ_IPC_FTP_CMD_DONE_SYST": MxAllWMessages(1, 50) = RegisterWindowMessage(MxAllWMessages(0, 50))
   MxAllWMessages(0, 51) = "FZ_IPC_FTP_CMD_DONE_TYPE": MxAllWMessages(1, 51) = RegisterWindowMessage(MxAllWMessages(0, 51))
   
   
   '   ...   Implement some more FTP commands here   ...
   
   
   
   Exit Sub
   
   
ErrorHandling:
   '...
End Sub

'#######################################################################################################################



Im folgenden Modul werden Variablen und eine API-Funktion definiert. Der Array 'MxAllWMessages' ist wichtig, um verschiedene Ereignisse voneinander trennen zu können (s. Erläuterungen oben). Einige FTP-typische Ereignisse sind in dem oberen Modul als Beispiel umgesetzt (z.B. 'FZ_IPC_FTP_CMD_DONE_SYST').
Die Win API Funktion 'BroadcastSystemMessage' löst WMessages an das System aus (s.unten).
'#######################################################################################################################

Code: Select all

Option Explicit
Option Private Module
Option Base 0


'Array for all WMessages:
Public MxAllWMessages As Variant    'For looping through all WMessage identifyers and triggering their last 3 chars (Col_0=Name, Col_1=Long)


'Bradcasting WMessages. This Win API causes Windows to send 'User Defined Messages' to other running applications on the system:
Public Declare Function BroadcastSystemMessage& Lib "User32" _
                                                (ByVal dw As Long, _
                                                pdw As Long, _
                                                ByVal un As Long, _
                                                ByVal wParam As Long, _
                                                ByVal lParam As Long)
            'Parameters
            '  dw Long, one or more of the following constants:
            '           BSF_FLUSHDISK = &H4              Disk is flushed each time a message is processed
            '           BSF_FORCEIFHUNG = &H20           If target is hung, expires after a timeout
            '           BSF_IGNORECURRENTTASK = &H2      Sending task does not receive the message
            '           BSF_LPARAMBUFFER = ???           lParam points to a memory buffer
            '           BSF_NOHANG = &H8                 Skips any processes that are hung
            '           BSF_NOTIMEOUTIFNOTHUNG = &H40    ?
            '           BSF_POSTMESSAGE = &H10           Message is posted, not compatible with BSF_LPARAMBUFFER or BSF_QUERY
            '           BSF_QUERY = &H1                  Sends the message in processes in sequence, going to the
            '                                      next process only if the previous one returns TRUE
            '  pdw long, one or more of the following constants:
            '           BSM_ALLCOMPONENTS = &H0          Message goes to every system component that can receive a message
            '           BSM_APPLICATIONS = &H8           Message goes to applications
            '           BSM_INSTALLABLEDRIVERS = &H4     Message goes to installable drivers
            '           BSM_NETDRIVER = &H2              Message goes to network drivers
            '           BSM_VXDS = &H1                   Message goes to system device drivers
            '  un       long, the message number
            '  wParam   Long, depends on the message
            '  lParam   long, depends on the message. If BSF_LPARAMBUFFER is specified, this is
            '                                      the address of a memory buffer in the calling processes
            '                                      address space and the first 16bit word in the buffer contains
            '                                      the length of the buffer
            'Return value: long, greater than zero on success. -1 in error. Zero if BSF_QUERY is set and at least on emessage recipient returned zero.
            'Platforms:    NT4, W95
            
'Constants for BroadcastSystemMessage:
Public Const BSF_FLUSHDISK = &H4
Public Const BSF_FORCEIFHUNG = &H20
Public Const BSF_IGNORECURRENTTASK = &H2
'Public Const BSF_LPARAMBUFFER     =    ????
Public Const BSF_NOHANG = &H8
Public Const BSF_NOTIMEOUTIFNOTHUNG = &H40
Public Const BSF_POSTMESSAGE = &H10
Public Const BSF_QUERY = &H1
Public Const BSM_ALLCOMPONENTS = &H0
Public Const BSM_APPLICATIONS = &H8
Public Const BSM_INSTALLABLEDRIVERS = &H4
Public Const BSM_NETDRIVER = &H2
Public Const BSM_VXDS = &H1

'#######################################################################################################################



In FileZilla könnte quasi nach jedem relevanten Ereignis (falls sinnvollerweise ein entsprechender Boolean auf einer config-Seite auf true gesetzt wurde) diese eine(!) Zeile eingefügt werden, die im folgenden Modul mit 'RetVal = BroadcastSystemMessage' beginnt:
'#######################################################################################################################

Code: Select all

Option Explicit
Option Base 0
'Option Private Module

Dim z&                        'Ordinary counter

Private Sub Command1_Click()
   Dim RetVal&
   
   'Check, weather a valid string was inserted:
   For z = LBound(MxAllWMessages, 2) To UBound(MxAllWMessages, 2) Step 1
      If MxAllWMessages(0, z) = Form1.Text1.Text Then
         'Fire WMessage:
         RetVal = BroadcastSystemMessage(BSF_POSTMESSAGE, BSM_APPLICATIONS, MxAllWMessages(1, z), &H0, &H0)
         'Exit For-loop:
         GoTo SuccessfulFired
      End If
   Next z
   'No item in array matched (no event name was identical to user entered description)
   MsgBox "In this sample, no event name is implemented like the one you entered." & vbNewLine & "To give an example, the first of the list implemented is:" & vbNewLine & MxAllWMessages(0, 1)
   
SuccessfulFired:
   'Check success:
   If RetVal = 0 Then MsgBox "Broadcasting this message failled."
   Text1.SelStart = 0                  'Select the whole entry of last WM
   Text1.SelLength = Len(Text1.Text)   'Enable to overwrite whole Text1.Text
End Sub

'#######################################################################################################################



In einer beliebigen, von einem interessierten Admin zu schreibenden Anwendung, könnte dann ein solcher Event aufgefangen und mittels der Evaluierung des Long-Wertes einem dezidierten Ereignis zugeordnet werden.
Sinnvollerweise kann das in einer CallBack-Routine passieren, die in Visual Basic so aussehen kann:
Merke: Damit ein im Millisekundenbereich einem vorherigen Event folgender Event auch evaluiert wird, ist hier (quick and dirty, denn die CallBack-Prozedur muß schnell wieder zur Verfügung stehen) ein Timer implementiert, der, nachdem der spezielle Event ermittelt und in 'strWMessageTrigger' gespeichert wurde, innerhalb der Timer-Routine die entsprechenden Aktionen startet (hier den Namen des Events in eine TextBox einträgt).
Der implementierte Timer ist jedenfalls aureichend, solange zwischen einem und dem nächsten aufgefangenen Event mehr als ca 200ms vergehen.
'#######################################################################################################################

Code: Select all

Option Explicit
Option Base 0
Option Private Module

Dim z&                        'Ordinary counter

Public Function sysSubWndProcIpc(ByVal hwnd As Long, ByVal MSG As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
   'On Error GoTo ErrorHandling
   'NOTE: NO 'ErrorHandling', because this would CallBack make to fail !
   
   'Ignore this proc (CallBacks) as long as this proc is running (avoid recursives):
   'NOTE: This may occour extremely seldom (if ever), because this proc may last for less then some milli seconds !
   If bolIpcIsRunning = True Then Exit Function      'Skip if already/still running a previous user defined Windows Message
   bolIpcIsRunning = True                            'Set to skip
   
   'Ignore this user defined WMessage (IPC), if a previous one is still on progress:
   'NOTE: This may occour sometimes, because 'TimerIpc.Interval' will be reset to zero(0) AFTER some long procedures like adapting the
   '      interface to another language, or termination of an executable (unloading all forms, processing Unload-Call-proc-links and more) !
   
   
   If strWMessageTrigger <> "" Or frmIpc.TimerIpc.Interval > 0 Then
   'NOTE: 'strWMessageTrigger' will be reset at end of sysIpcTimer (after having finally processed this User Defined Message ! )
      '<Nothing>, because still an other IPC is on progress (works if a message may become ignored without causing problems)
      'If 'many' simultaneously incoming and important messages may occour, it might be useful to either
      ' - code a stack for storing an actual incoming message (and what has to become processed later after another reaction which is on the run has finished), OR
      ' - code a logging for at least beeing able to track what user defined message occourred while another (previous) reaction on a message was still in progress and caused this actual message to be ignored.
   
   ElseIf lngMsgIdLBound <= MSG And MSG <= lngMsgIdUBound And IsArray(MxAllWMessages) = True Then
   
   'NOTE: IsArray(MxAllWMessages) is for security reasons, because otherwize on prog termination ('F4') the array is set to
   '      Nothing before unloading this module and the CallBack on system events raising this module, will cause an error !
   'NOTE: Possibly more than 99% of all messages are OS messages which all will be ignored immediately here (asap), because
   '      the first User Defined Message to be registered ('FZ_IPC_FTP_CMD_DONE_0') will get the smallest long message handler !
   
      'Find Long numeric: Loop through all messages (and find the one with the matching messages handler):
      For z = LBound(MxAllWMessages, 2) To UBound(MxAllWMessages, 2) Step 1
         
         'If the WMessage caught has got the same message ID like one of the registered one, determine which one it was:
         If MxAllWMessages(1, z) = MSG Then
            
            'Remind 3-char User Defined Message Name of IPC message:
            strWMessageTrigger = MxAllWMessages(0, z)
            'STATUS: THE NAME OF USER DEF WIN MESSAGE IS DETERMINED, THE MESSAGE NAME LONG IS STORED IN 'strWMessageTrigger' !
            
            'Set timer in frmIpc form, if an user defined Windows message event was caught:
            frmIpc.TimerIpc.Interval = intIpcDelay             'Set interval
            'STATUS: WITHIN THE PERIOD OF 'intIpcDelay' THE TIMER EVENT WILL RISE THE PROC 'sysIpcTimer' TO TRIGGER THE RELATED ACTIONS !
            
            'Exit For-loop asap:
            Exit For
            
         End If
      Next z
   
   Else
      '...
   End If
   
   'Call former WinProc:
   
   'Reset, not to skip execution (to be ready for the next WMessage):
   bolIpcIsRunning = False
   
   'Effectively start CallBack here (as last action in proc and AFTER setting 'strErrEnv' and the Boolean to trigger a running IPC!):
   sysSubWndProcIpc = CallWindowProc(PrevWndProcIpc, hwnd, MSG, wParam, lParam)
   
End Function

'
'#######################################################################################################################



Der Timer-Event könnte in VB z.B. so aussehen:

'#######################################################################################################################

Code: Select all

Option Explicit
Option Base 0
Option Private Module

Sub sysIpcTimer()
   On Error GoTo ErrorHandling
   
   'This proc is managing the Inter Process Communication (IPC) between one app (like FZ) and another app (like an UpTime controlling
   'watchdog for FZ).
   'It is working like this:
   'A user defined windows message (WM; lngNumber is system wide defined e.g. as 'FZ_IPC_FTP_CMD_DONE_0') is sent by one app (e.g. FZ)
   'or by another (e.g. WatchDog) and will be received by both (WatchDog and FZ). Each WM (long numeric) is triggering a well defined action,
   '(in WatchDog and/or in FZ and/or simultaneously in any other app systemwhide). Any app receiving a WM, raises by CallBack its 'sysSubWndProcIpc',
   'sets (1)a timer to a positive interval and (2)sets 'strWMessageTrigger', to the name of the user defined WM that was detected
   'by 'sysSubWndProcIpc'. After these two(2) actions, 'sysSubWndProcIpc' will restart the CallBack and exit (for NOT crashing on
   'long actions to do within 'sysSubWndProcIpc'. The timer event then calls this 'sysIpcTimer' and the 'strWMessageTrigger' is
   'evaluated for getting to know what WM was received (and launching the proc for that messaged IPC).
   'NOTE: Both, (1)the 'frmIpc.TimerIpc.Interval' and (2)the 'strWMessageTrigger' must be reset to effectively process a next incoming IPC WMessage,
   '      because it MUST be sure, that any previous IPC messages are completely finished !
   '      (Possibly the WMessages caught, might become stored into a stack and processed separately and possibly asynchroneously).
   'Note: It is NOT a problem to fire hundrets of WMessages (besides of the load) for the fiering app (here FZ).
   '      The problem may only arise in teh app that receives more WMessages as it is time to process them, if they were not cached in an array
   '      for later (and possibly asynchroneous) work on them.
   '      NOT FZ may crash because of eventually too many fired events, but the receiving app WatchDog, if it has no propper event handling implemented!
   
   Dim i&                        'Ordinary counter
   Dim s$                        'Dummy for string operations
   
   'Run:
'DEBUG:     strWMessageTrigger
   
   'CAUTION:
   'Within 'sysSubWndProcIpc' two(2) switches are reminded, to process a caught WMessage: (1)the frmIpc.TimerIpc.interval, (2)the 'strWMessageTrigger' !
   'This results in the need to reset these both(!) values to zero(0) and "" to make 'sysSubWbdProcIpc' sensitive for the next IPC message !
   'The 'TimerIpc.Interval' is reset to zero(0) next, the 'strWMessageTrigger' is reset to "" at bottom of this module !
   
   'Reset the timer event for NOT raising this proc a second time asap:
   frmIpc.TimerIpc.Interval = 0              'For security reasons reset the timer
   'NOTE: If the interval is small (e.g. a '1'), the timer might call this proc a second time, before it is set to zero(0) !!!
   
   'For security reasons, exit if nothing is stored within 'strWMessageTrigger' :
   'NOTE: Into 'strWMessageTrigger' was written the IPC identifyer 3 chars long.
   If strWMessageTrigger = "" Then
      'If no User Def WMessage is still reminded in 'strWMessageTrigger', end with this proc:
      GoTo EndSelect                                     'Go to end of procedure
   End If
      
   Select Case strWMessageTrigger      
      
      'By the number, the processed event within FZ will become triggered:
      Case Is = "FZ_IPC_FTP_CMD_DONE_ABOR"
         'Note that while debugging this module, you might cause the system to raise events in the meantime and this app would like to
         'processe the next CallBack on the module '', but this module in the foreground is preventing the CallBack beeing processed!
         'therefore try not directly to insert a string into a TextBox (what would raise a windows event), but reminde what to process
         'by storing the task in an array and process it somewhere else.
         
         Form1.List1.AddItem "FZ finally performed a FZ_IPC_FTP_CMD_DONE_ABOR", 0
      
      
      '   ...   Implement some more FTP commands here   ...
      
      
      'By the number, the processed event within FZ will become triggered:
      Case Is = "FZ_IPC_FTP_CMD_DONE_MKD"
         Form1.List1.AddItem "FZ finally performed a FZ_IPC_FTP_CMD_DONE_MKD", 0
      
      
      '   ...   Implement some more FTP commands here   ...
      
      
      'By the number, the processed event within FZ will become triggered:
      Case Is = "FZ_IPC_FTP_CMD_DONE_STOR"
         Form1.List1.AddItem "FZ finally performed a FZ_IPC_FTP_CMD_DONE_STOR", 0
      
      
      'By the number, the processed event within FZ will become triggered:
      Case Is = "FZ_IPC_FTP_CMD_DONE_STOU"
         Form1.List1.AddItem "FZ finally performed a FZ_IPC_FTP_CMD_DONE_STOU", 0
      
      
      '   ...   Implement some more FTP commands here   ...
      
      
      'By the number, the processed event within FZ will become triggered:
      Case Is = "FZ_IPC_FTP_CMD_DONE_SYST"
         Form1.List1.AddItem "FZ finally performed a FZ_IPC_FTP_CMD_DONE_SYST", 0
      
      
      'By the number, the processed event within FZ will become triggered:
      Case Is = "FZ_IPC_FTP_CMD_DONE_TYPE"
         Form1.List1.AddItem "FZ finally performed a FZ_IPC_FTP_CMD_DONE_TYPE", 0
      
      
      '   ...   Implement some more FTP commands here   ...
      
      
      
   End Select
EndSelect:
   
   
   strWMessageTrigger = ""                         'Reset trigger information
   'NOTE: Do NOT remind a new 'strWMessageTrigger' in 'sysSubWndProcIpc' (nor set the timer interval to >0 ), if the 'strWMessageTrigger'
   '      still is NOT a NullString, because then, any WMessage is still on progress and setting the timer interval and strWMessageTrigger,
   '      would lead to troubles, because this sysIpcTimer would be called a second time before the previous IPC has finished its progress !
   
   
'If bolIsRuntime = False Then Stop   '
   Exit Sub
   
   
ErrorHandling:
   '...
End Sub

'#######################################################################################################################

[swdld]

Daß Euer Forum blancs am Zeilenanfang löscht, macht den Code nicht besser lesbar