Does anyone have a known, solid solution for the scheduling of events (i.e. appointments, meetings, etc) within a system. I'm speaking here of "events" as tasks that need to be done on a one-time or recurring basis and executed based on a schedule. I've found a schedule UI component by DevExpress and it has some reference to using custom objects but I figure someone must have solved this problem nicely already. Thanks in advance everyone for the time and effort.
Byron Crowell
Here's a nice discussion of scheduling in .NET from Ayende.
Related
I need to add columns to a salesforce report dynamically(based on particular conditions). I'm planning to do this with a trigger that is looking for my conditions. My two questions,
Is it possible to adding columns dynamically for a Report?
Can we schedule triggers based on time intervals instead of database updates?
Thanks, BR
Madura
I'm not aware of any possibility to manipulate Reports from Apex. Report definitions can be retrieved and modified with Metadata API (the one used in Eclipse IDE for example) but that means you'd have to use hacks since Metadata API is not easily available in Apex.
It's a kind of "known problem" and many people have already researched it:
http://boards.developerforce.com/t5/Apex-Code-Development/Is-it-possible-to-call-Metadata-API-from-Apex-code-Getting-Error/td-p/119412
https://github.com/financialforcedev/apex-mdapi - looks really interesting I'd say
https://salesforce.stackexchange.com/questions/1082/has-anyone-ever-successfully-invoked-the-metadata-api-from-within-apex
Do you really think that some kind of "dynamic report" is a valid solution for business need though? I mean - users would be confused if they added some columns to the report and next day the report definition will change wiping out their work...
As for the other question - you probably shouldn't use the word "trigger" ;) If you want some Apex to run in time intervals you should have a lookt at job scheduling (write a class that implements Schedulable) and then you can schedule it to run at specific times. Without special tweaking the job can fire even every hour.
Of course there's also option of time-based workflows that would perform a field update and cause some real trigger to fire but that's very data-centric - no guarantees that it will run at time intervals.
I'm writing a WPF application using a MVVM pattern and using Prism in selected places for loose coupling, and I'd like to have logging messages shown in a window and written to a file. The subset of messages going each way may not be the same.
I think I should publish a message through the EventAggregator (MS-Prism implementation of observer pattern) and have two objects subscribe: one that updates the LogWindowViewModel and one that logs using the Enterprise Library logger. Is this a good idea or am I duplicating something that's already implemented?
The fact that the log message will be different in each output is the limiting factor.
Extending the block may suffice and defining a CustomTraceListener or ILogFilter may work out for you. This would avoid needing to use the EventAggregator.
It boils down to who has the knowledge of what and where to log. Are the differences driven off values within the logging engine such as severity? Are they instead driven by the consumer of the logging engine and therefore tightly coupled to the class itself? These types of questions will dictate your choice.
Leveraging the extension points in the logging block would be my first choice before having to rely on using the EventAggregator.
I think an idea is fine. There is not so much functionality to be duplicated it seems
I used Common.Logging as data collector, filter and distributor for something comparable and wrote a custom appender for my own processing and ui-output.
I am wondering if it's possible to create a graphical application in Silverlight which supports synchronisation between the different clients.
To be a bit more precise, I am drawing concepts of developing a Silverlight Game. Visitors would log-in, and see live, synchronised what the other vistors are doing.
If it is possible to have this implemented, I would like to know what is needed to create a fully synched Silverlight environment between multiple peers. Anything from links, code snippets, ideas and / or alternatives are more than appreciated !
Please do not suggest Flash, as I do not own a valid Flash building license, I prefer to have this created within Visual Studio 2010.
Edit:
I want it to be as lightweight for the clients as possible, I don't care much for the server, and also low bandwidth consuming. I don't know whether a broadcasting principal is the only option to have all the events taken place at the same time?
You may want to take a look at the Polling Duplex protocol of WCF. This is the subscription and publish concept. Support in SL has been about since version 2 so there's plenty of articles out there. An article I referenced for a message broadcast system we put in place at work can be found here...
http://tomasz.janczuk.org/2009/07/pubsub-sample-using-http-polling-duplex.html
which also mentions an interesting project on codeplex (I've not used)...
http://laharsub.codeplex.com/
A simple and working (but rather inefficient) solution would be for all clients to ask a WCF/Ria service on the server for status updates in regular intervals, perhaps once every X seconds or so, letting the server keep track of changes relevant to the calling clients.
In my WPF application I need to do an async-operation then I need to update the GUI. And this thing I have to do many times in different moment with different oparations. I know two ways to do this: Dispatcher and BackgroundWorker.
Because when I will chose it will be hard for me to go back, I ask you: what is better? What are the reasons for choosing one rather than the other?
Thank you!
Pileggi
The main difference between the Dispatcher and other threading methods is that the Dispatcher is not actually multi-threaded. The Dispatcher governs the controls, which need a single thread to function properly; the BeginInvoke method of the Dispatcher queues events for later execution (depending on priority etc.), but still on the same thread.
BackgroundWorker on the other hand actually executes the code at the same time it is invoked, in a separate thread. It also is easier to use than true threads because it automatically synchronizes (at least I think I remember this correctly) with the main thread of an application, the one responsible for the controls and message queue (the Dispatcher thread in the case of WPF and Silverlight), so there's no need to use Dispatcher.Invoke (or Control.Invoke in WinForms) when updating controls from the background thread, although that may not be always recommended.
As Reed said, Task Parallel Library is a great alternative option.
Edit: further observations.
As I said above, the Dispatcher isn't really multithreaded; it only gives the illusion of it, because it does run delegates you pass to it at another time. I'd use the Dispatcher only when the code really only deals with the View aspect of an application - i.e. controls, pages, windows, and all that. And of course, its main use is actually triggering actions from other threads to update controls correctly or at the right time (for example, setting focus only after some control has rendered/laid-out itself completely is most easily accomplished using the Dispatcher, because in WPF rendering isn't exactly deterministic).
BackgroundWorker can make multithreaded code a lot simpler than it normally is; it's a simple concept to grasp, and most of all (if it makes sense) you can derive custom workers from it, which can be specialized classes that perform a single task asynchronously, with properties that can function as parameters, progress notification and cancellation etc. I always found BackgroundWorker a huge help (except when I had to derive from it to keep the Culture of the original thread to maintain the localization properly :P)
The most powerful, but also difficult path is to use the lowest level available, System.Threading.Thread; however it's so easy to get things wrong that it's not really recommended. Multithreaded programming is hard, that's a given. However, there's plenty of good information on it if you want to understand all the aspects: this excellent article by our good fellow Jon Skeet immediately jumps to mind (the last page of the article also has a good number of very interesting links).
In .Net 4.0 we have a different option, Task Parallel Library. I haven't worked with it much yet but from what I've seen it's impressive (and PLINQ is simply great). If you have the curiosity and resources to learn it, that's what I'd recommend (it shouldn't take that much to learn after all).
BackgroundWorker is nice if you're doing a single operation, which provides progress notifications and a completion event. However, if you're going to be running the same operation multiple times, or multiple operations, then you'll need more than one BackgroundWorker. In this case, it can get cumbersome.
If you don't need the progress events, then using the ThreadPool and Dispatcher can be simpler - especially if you're going to be doing quite a few different operations.
If C# 4 is an option, however, using the Task Parallel Library is a great option, as well. This lets you use continuation tasks setup using the current SynchronizationContext, which provides a much simpler, cleaner model in many cases. For details, see my blog post on the subject.
I am having to build a web app that has an event calendar section. Like in Outlook, the requirement is that users can set up recurrent events, and can move individual events around within a series of events.
What methods could one use to store (in a database) the various ways you can describe the recurrence pattern of a series?
How would one record the exceptions?
What strategies do you use to manage redefining the series and its effects on the exceptions?
I've done this a couple of times, differently, but I'd like to see how others have tackled this issue.
Have a look at how the iCal format deals with recurrence patterns and recurrence exceptions. If you want to publish the events at some point, you will have a hard time avoiding iCal anyway, so you could just as well do it in a compatible way from the start.
For one thing: if you're not already familiar with it, take a look at RFC 5545 (which replaces RFC 2445) which defines the iCalendar specification for exactly this kind of pattern.
I've typically provided front-end logic that allows a user to specify a recurring event, but then actually used individual database entries to record the events as seperate records in SQL server.
In other words, they can specify a meeting every Monday night at 7PM, but I record 52 records for the year so that individual meetings can be changed, deleted or additional information added to those events.
I provide methods to allow the user to cancel all future events, and then re-enter a new recurring series if they need to.
I've not come up with a perfect way to handle this, so I'll will monitor this thread to see if any great suggestions come up.