05-19-04 10:49 PM
Hi
By having the expiry date to tomorrow, there's already customization done in
the workflow event handlers. So that part of the code works. From what you
have described, it seems that you may be having problems reading the
contents of the placeholder when it's being created for the first time. I've
tried using Request.Form["PlaceholderName":] to access the contents of t
he
placholder in the event handlers. That worked. However, I should add that it
caused my application to behave a little strangely after. The cause was
never traced but was attributed to something related to a database
inconsistency.
Instead of using the workflow event, have you considered writing a control
that saves the values directly to the start and expiry date property of the
posting? Stefan has an excellent sample written in his blog, you can find it
here:
http://weblogs.asp.net/stefan_gossn.../25/119613.aspx
Trevor
"microsoft.public.sharepoint.portalserver" <john-danielt@intergen.net.nz>
wrote in message news:uy%23UwwSOEHA.2876@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> I am writing an application that has two custom date pickers as
placeholders
> on a posting. I have written a custom handler in the global.asax so that
on
> approval, if the posting is one that contains these two date pickers, it
> should set the value of Start Date and the expiry date.
>
> However, it seems that when accessing the rawdata of the datepicker
control
> before approval gets the default date (eg, todays date). It is only after
> approval that I can programmatically get the value of this placeholder -
I'm
> guessing that the data doesn't get persisted in an accessable way until
> after approval.
>
> What this means is that when a user creates a page, they set the two date
> pickers, then save and exit, approve, but the start date and expiry date
are
> set to start today and expire tomorrow (this is due to the default
values).
> However, when the user then edits the page and re-saves and approves, the
> start date and expiry date are set correctly as the values are now
> accessable.
>
> This is obviously not the desired solution, does anyone have some ideas on
> how to overcome this problem?
>
> John-Daniel Trask
>
>
[ Post a follow-up to this message ]
|