I want to find out whether there is an outlook event due to start in the next five minutes.
I have the script below:
set now to current date
set end_time to now + (5 * minutes)
tell application "Microsoft Outlook"
set number_of_events to count (every calendar event whose start time is greater than or equal to now and start time is less than end_time)
end tell
Which works for most events, but seems to ignore recurring events. Any ideas how to include these?
Recurring events are poorly handled via Applescript. AFAIK there is no way to grab information about the current instance of a recurring event. The only way is to break the recurrence and convert it into a standalone event.
This tread is relevant and may have a partial solution.
Related
I am new to jBPM. I am working on jBPM version 6.2.0. I want to perform following tasks.
Send reminder email to user / group.
Remind the user again after 1 business day if the task is not yet complete. Continue to send reminder everyday untill the task is done.
Also what happens if jboss / tomcat server restarts after sending one reminder email. Will the later emails still schedule ?
I am able to add Deadlines (Escalation- Notification) But it runs once and sends only 1 email. I need to keep reminding the user on a daily basis (or hourly) to complete the task.
I tried looking in jBPM 6 user guide but it does not have clarity about Boundary timer events and intermediate catch time events. And when i use any of them then it runs once.
Any help is much appreciated.
Here is an example of something that I did recently for sending periodic emails.
This should loop until a user finally completes the task. You might have trouble with the one business day rule since I do not know if the ISO 8601 spec is flexible enough to know about weekends/holidays/business days. You could add that logic into your service task for sending the email.
Be aware that this loop will continue forever until the task is complete. You might want to consider adding some additional timeout. You could add a loop count so after X amount of times the process will be cancelled. Some of my processes have a rule that if the process is not complete in Y days, the process should be cancelled. I accomplished that by have a process variable CancelDate and set a Timer Event definition to Date/Time and the value #{CancelDate}.
I've been trying to create notifications that happen on a weekly basis - for example, every monday at 8am.
I've tried to use a recurring toast for this - http://msdn.microsoft.com/en-us/library/windows/apps/hh465417.aspx - but realized that the recurrence parameters are more designed for a snooze functionality, with a maximum delay of 60 minutes, and a maximum repeat for 3 times.
Is there a suggested workaround for this?
Is there a best practice for such a use case?
Thanks!
You're right that the recurrence on scheduled toasts is designed for snooze. Unfortunately, the API doesn't provide a way to show the same toast multiple times on a fixed schedule.
You'll need to manually create a ScheduledToastNotification each time you want it to be shown. In your example, you might create and schedule out a toast a week for each Monday at 8 AM.
There are couple of apps at the Windows Phone Store which are automatically updating phone lock screen by a custom interval, lets say 1, 2, 4 or more hours.
I did some search over internet to find some articles or best practice to implement custom update interval, which is bigger than 30 minutes but without any result.
Maybe you know some code snippets or reference on articles ?
Thanks in advance!
As you have already found, the periodic agents are invoked once every 30 mins. However, you can simply do nothing until your desired update period has passed then execute your update.
You already have access to your app's isolated storage from within your background agent. You can simply store a counter in some file to track the time that has passed and once it meets your requirement you can execute your update and reset the counter.
Example: Lets say I have a workflow which send an email 2 days before warranty enddate.
This workflow is triggered on the "Created" of a entity.
step 1: wait condition - process timeout < (warrantyendate - 2)
after wait: send email.
So when the record is created, the workflow is started. But what happens when the user goes back and updates the warranty enddate.
Does the workflow check the updated warranty enddate or does it still use the enddate entered when it was triggered (i.e the initial on create value)?
My understanding is that the workflow uses the data in the system at the time of execution.
The important thing to take note here is that a workflow can be executed many times, at these times the data in the system can be different. Crm caches the state of the workflow, but not the data. Process Architecture for Microsoft Dynamics CRM 2011 describes this.
So, each time the process timeout condition is checked it will use the current value of warrantyEndDate. If the value is changed, next time the condition is checked the new value will be used.
In any case as #BenPatterson1 suggests, you are probably best just testing to be sure.
After trying this myself, if the value of the field included in the condition changes, the workflow engine fires up from sleep(waiting) and checks the condition again.
If it meets the condition, then continues to the next step or will continue to wait.
I'm using the scripting bridge to query iTunes from my cocoa application. Sometimes iTunes pops up a window (like if an ipod needs updating etc.) and while that popup window is open I can't get any information from iTunes. So if I request information from iTunes when it's in this state my application completely locks-up until that popup window is dismissed.
So I need some sort of mechanism where I can ask itunes something simple in a separate thread to see if I can get a response from it... and if that separate thread doesn't receive a response within a short period of time my main thread will just kill that thread and thus know not to query itunes at that particular time.
Any ideas how to create such a mechanism? I searched for ways to kill a thread but haven't found any.
Your problem is nothing to do with threads; it's that your timeout is too long. Whatever you're doing should fail after about a minute.
To fix this, send a setTimeout: message to the SBApplication object, passing the amount of time you want it to wait. The value is in ticks, of which there are exactly 60 per second.
(Some sources say 60.15, and Apple's own docs say “approximately” 60, but I just measured ten minutes' worth of TickCount, and the result of the division by 600 seconds is exactly 60.0. The code I used:
NSLog(#"Ticks per second: %f", (end - start) / (60.0 * numMinutes)); where end and start are results from TickCount.)
Check out NSOperation/NSOperationQueue.