Log In
Register
Members
Home
Add Reply
Add Topic
Topic RSS
12:35 pm
QuoteI see that FQ is none too pleased about moving messages and printing them.
I have tried a few work arounds, but none seem to work (move then print, print then move)
print in one rule set, move in another rule set.
I also noticed a request to create what i best regard as a cron job.
My thought is a cron job would work with a two rule set up:
Filter 1 prints
Filter Cron job option (at scheduled interval) runs, processing Filter 2
Filter 2 moves emails with same parameters as Filter1 to the desired location
Similar in concept, I recall a sleep function in java (been 3 years since I was working as a programmer) that I was hoping could be implemented at end of filter 1 (print) which would then awaken and continue filter and move the messages.
I am unsure if this would work tho, as I see tonequilla notification after print also munges up the print function (tried that yet?) (ie prints blank sheets with time/date stamps only
Any of this seem do-able?
Thanks for your efforts, this has made me one step closer to replacing all outlook functionality I had previously utilized.
C
Offline
The basic issue is that move is trying to delete the message, which interferes with Print that wants to read it.
What I have done is to implement a "Move Later" action that delays the move, hopefully giving enough time for the print to finish before the move deletes the action. If you want, you can download this from http://mesquilla.com/filtaquil……1.1.2.xpi
I was planning to wait and do a release 1.2 soon that would have this feature as well as others, but you are welcome to try this interim release if you want. You will need to use a "Move later" move instead of a normal move.
8:04 am
Interesting how move is really a delete function.
Be my pleasure to give it a try.
Hopefully I can provide some useful feedback.
9:25 am
Wondering how it is intended to operate in the workflow.
A quick test did not seem to work, but I set it up as secondary to the print function.
I do not see it as a filter option (except for the toggle section).
All that is apparent is the usual move message to.
Is your intention that it should be part of a seperate filter run further down the list or run inline with a print option in a single filter?
Another truly lame question, as I am a tb newby, should I uninstall the 1.1.0 before installing 1.1.2?
Thanks again for the tremedous effort you are putting into this
Did you enable the new filter action in the addon/options section, then restart?
As for where to apply it, it does not really matter. Typically it would be in the same filter as other related actions, there is no advantage to having it in its own filter.
11:17 am
Ah, the restart was the key.
It worked like a champ.
As I process more I will follow up and let you know if I observe any issues.
Again, great job
10:03 am
Seemed to work fine when used in a test situation:
copy email to inbox, run filter, worked.
Unfortunately, It appears that it is not working in a live environment:
email arrives at inbox, should print email in full, then move to an "orders" folder
It is printing with the undesirable no boby/header/etc, just date and label stamps, as the earlier iteration.
However, there are tweaks I am making and will report back later.
I had not uninstalled only disabled autoprint (whose author suggested your add onto me)
My impression at the moment is that the move later needs a longer detent period before copy/paste/delete after print.
I will report back he next time it is runs.
That will see if the removal of the autoprint add on had any impact.
Corey
For the "Save Message as File" filter action, I was able to detect the completion of the save, and then do the move at the appropriate time. For other actions though, it just does a default delay. I was concerned that the problem you are seeing might occur, and unfortunately that appears to be the case.
I see in the code that I am only providing a 5 second delay except for the "Save Message as File" case. It would be pretty easy to lengthen that, but it is still a bit of a kludge unless I figure out how to detect the end of the message print.
So what would the appropriate delay be in your live environment? What I will probably do is to set a default value of, say, 60 seconds but allow that to be adjusted with a hidden preference that can be set by the user.
10:24 am
Test failed.
Will try move later as a seperate secondary filter set from print.
More news as it is available
1:26 pm
Unfortunately running as 2 seperate filters had no improvement.
As you note the delay time can be lengthened, I believe may be the solution.
5 seconds may be plenty, and in my case 60 seconds is not detrimental.
A minute is probably more than enough.
If you would like me to test out that tweak I will be happy too.
I suspect it is not the message end that is the problem, but the cycles/msecs for processes to parse from one execution to the next.
I think your concept of a user adjustable duration is great, as many folks may have a use case where that would be beneficial.
Again, I offer myself as your guinea pig for both solutions, on your time.
I have gotten by without a functional solution in the last few weeks since my migration from outlook to TB, waiting a little longer is no problem.
Again, many thanks
Corey
Try this file:
http://mesquilla.com/filtaquil……1.1.3.xpi
I have added a new preference "extensions.filtaquilla.moveLaterDelay" which is the delay (in milliseconds) for the move later, defaulting to 5 seconds (5000).
1:48 pm
Sorry for the delay, sick family had me unable to implement and test for a while.
Seems to still not be happy.
If I am being aware enough, it seems that the move later is retarding, nah, preventing, printing of multiple emails that arrive at about the same time (same read from server) that meet the filter parameters.
Plus what does print is the one 1 blank page that has been the issue all along.
I am unsure if they are related or not.
My thought is that later, should be its own filter function, basically a sleep command, with settable intervals, in say, millis.
That may do it, perhaps the seperation of states may be the piece of the puzzle.
Or maybe a combination of move later and ?print later?
Out of curiosity, how are you testing on your end when tweaking the code?
Corey
Yes I do test this after I tweak the code, but only in very simple situations since I do not use the print message action myself routinely.
I'm sort of running out of ideas for simple tweaks. What I really need is a method in the core code to programatically detect the end of the print, and I have not been able to find it. I may try to work on it some more later, but for now I have no further suggestions.
Most Users Ever Online: 18
Currently Online:
10 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Member Stats:
Guest Posters: 130
Members: 565
Moderators: 1
Admins: 1
Forum Stats:
Groups: 1
Forums: 7
Topics: 231
Posts: 802
Newest Members: Matteo, p.dobrogost, gaute, Mythobeast, terry, Livraria Notre Dame
Moderators: rkent (323)
Administrators: rkent (323)
Recent Comments