Hello 9Val,
I apologise for my late reply.
M>> This is why I would say that *only_one_move_action* should be allowed in
M>> a filter.
>
> It is closer to truth :) and sounds like suggestion, well, will be
> done
Great!
M>> I have actually replied to that I think. There should only be one move
M>> action. If the user wants more c_o_p_i_e_s, he should use the copy
M>> action.
>
> I talked about any other action like parking message. I don't
> understand why do you think that after moving it has no sence in other
> operation while message is still accessible?
That is exactly my point. To be consistent with what 'move' (which can
be considered equivalent to cut&paste) generally means, I think and
believe that the message should not be considered to be available for
any 'manipulation' after it has been moved. My general concept of how
any filter should work at execution time is:
Start filter execution
Get message from Source folder into _Working area_
Manipulate message _in_ working area
...
Copy working area to some folder A
More manipulation allowed
...
Move working area to destination folder B
...
IF NO move action has been performed
Move working area back to source folder
END if
End filter execution
The COPY action will copy the message in working area with any
manipulation done before the copy.
The Move action will move (copy) the message in working area with any
manipulation done before the move .AND. empty (delete) the working area.
Otherwise, what is the difference between doing a copy and a move?
M>> Would this mean that the user should be "spied on" and not allowed to
M>> add any actions after the move? No, not all. There are actions that can
M>> be perfectly be executed after the move is done, like for example
M>> playing a sound or sending some kind of auto-reply, etc. Also, the user
M>> may want to add an action (which can only be added at the end, BTW) that
M>> he has forgot and then move it up to where it should be.
>
> Why? If there is no copies order shouldn't play a big role and
> adding actions can be more intuitive - no add+adjust position, just
> add
What I was trying to point out was that, although it might be a good
idea to grey out on the list of available actions those that are
'impossible' to execute (because the work area is empty after the move),
it is not really a good idea because, since actions can at present only
be added at the end, the user may want to add an action
(apparently 'impossible') and then move it up to a slot where its
execution is 'possible'. I hope you now get my point.
M>> What if the user adds an "impossible" action after the move one and
M>> leaves it there?
>
> Example of such 'impossible' action?
According to my 'filter execution logic' above, any action like
flagging, etc., that requires that the message is still present in the
working area.
You shouldn't work on Sundays ;-)
--
Best regards,
Miguel A. Urech (El Escorial - Spain)
Using The Bat! v3.0.0
________________________________________________________
Current beta is 3.00.06 | 'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html
IMPORTANT: To register as a Beta tester, use this link first -
http://www.ritlabs.com/en/partners/testers/
