Boris Anders, [BA] wrote: >> I disagree. All three should be done since the message is still >> available for all three actions to be carried out. I'd certainly want >> all three to be done if I set them up to be done as such.
> Well, all three are carried out to the original message. The > original message is flagged, and parked. Yes. > But the copie isn't parked, .. because the copy is generated prior to the next action being carried out. If you wish the copy to be parked as well, then use the sequence <flag message> <park message> <copy message to..> In this way you can alter the message prior to copying/moving it to a new location. >> <delete message> >> <run external program> >> <play sound> >> Are you saying the latter two actions shouldn't be carried out? I >> disagree again. > Yes, with the my first suggestion, maybe the second is better: Ok, let's see. >>> Another solution would be, that TheBat! move these action at the end >>> of the list. > So TheBat! would sort: > <run external program> > <play sound> > <delete message> That would be presumptuous and could lead to problems. I haven't thought it through but I'd not wish the actions to be rearranged to carry out what TB! *assumes* the user meant. >> These bugs are simply bugs that need to be fixed. > And how? Actions should always be carried out in the sequence shown. Actions cannot be carried out on messages that have been deleted or moved to another location so all other message specific actions should be specified prior to deletions/moving. Actions after deletions/moving of messages will be carried out only if they are actions that do not need to be applied to the message itself, for example, running an external program or playing a sound. >> They aren't symptoms of filter actions needing to be nullified or >> preventing from occurring because of a prior action. > I disagree! The filter is: > <delete message> > <read message> > If you run that filter, the message disappear (deleted) and appear > again, because its marked as read. The problem is that a message that has been deleted cannot be acted on again. That's all. It's a nonsense sort of sequence and the bug lies there. > There are two possibilitys (which i can imagine) to solve this: > Sort > <read message> > <delete message> The user should make this the sequence, yes. It beats me why one would wish to do that anyway. > The problems are made by design - so correct the design, the problems > will disappear. A good help file will help here. We know that filtering and how it's carried out depends on the order of the filters. We can't get past that. This is the nature of filtering. The same goes for actions. They're carried out in sequence. In MDaemon, if the filter sequence is to: <delete message> <copy message to folder> The message is simply deleted and no copying is performed. To have the message copied and deleted, I have to make the sequence: <copy message> <delete message> >> The NFS works the same as MDaemon's filtering system. The actions >> are carried out as they're described in the filter rule. The rule >> itself, makes it seem to the user that the actions will be carried >> out in the sequence described. > Then the first sentence is wrong: NFS don't go in the sequence but > "random" This *is* the buggy behaviour I'm referring to. Or I should really be saying that IMO, this is buggy. Actions should be carried out in the sequence described. This is the only way one can accurately predict what will happen when the filter is applied. I don't see how it can function as you describe where actions are applied randomly and yet carry out complex actions as this. <flag message> <copy message to> <delete message> The above filter should flag the message, then create a copy and place it in a specified folder and then delete the original. If that doesn't occur in sequence then unflagged messages may be copied to the specified folder or no message could be copied because the original is deleted before anything can be done with it. -- Allie Martin [List Moderator and fellow end-user] · My PGP-Keys: http://key.ac-martin.com · The Bat!™ v2.13 "Lucky" Beta/1 /·\ WinXP Pro (Service Pack 2) ..... A pessimist is never disappointed.
pgpyFx43G5sUO.pgp
Description: PGP signature
________________________________________________________ Current beta is 2.13 'Lucky' Beta/6 | '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/
