locked
Strange behaviour of the SPCalendarView control RRS feed

  • Question

  • Hi,

     

    I think we've found a bug, or at least something strange happening with the SPCalendarView control... which is not much documented yet, so it's a bit difficult to see what is normal and what is not, using this control.

     

    So here it is :

     

    - we've made a custom webpart, showing a SPCalendarView control,

    - the control shows some items of a Sharepoint list (which has several fields, in particular a Title and a Date)

    - it works fine, each item appears at the right date and with the right title

    - and when we click on an item, we configured the "DisplayFormUrl" of the SPCalendarItems so as to call the .aspx page containing the webpart itself

    - so the page is called by the SPCalendarView items, transmitting an "ID" parameter corresponding to the item clicked

    - the webpart is able to show a form when it detects the "ID" parameter, so a form is shown and the user can modify the item fields, then save it (the fields are updated in the SPList) and then, show the SPCalendarView again, with updated data

     

    Everything works fine. But here is the problem :

    Once an SPList item has been updated, when another item is clicked in the SPCalendarView, and the page called with another ID parameter, Sharepoint fails, saying the element doesn't exists on this url.

     

    We've spent a lot of days identifying the problem and trying to understand it, we didn't found the reason of this strange behaviour. That's why we thought about a bug in the SPCalendarView.

     

    Anyway, we solved our problem by :

    - configuring the "DisplayFormUrl" of the SPCalendarItems so as to call the .aspx page and transmit it a custom parameter called CUSTOMID, set to the ID of the item, whereas the "ItemID" of the SPCalendarItems is let unset

    - so when the page is called back by SPCalendarView, the request url looks like : ...ourpage.aspx?CUSTOMID=33?ID=

    - of course the page is able to deal with the CUSTOMID parameter and ignores the system ID parameter

    - and when we do that, Sharepoint does not fails even if SPList items have already been updated by the page

     

    Hope it can help someone... at least, not to loose too many time understanding the strange behaviour of the ID parameter of the SPCalendarView control !

     

    Friday, July 20, 2007 4:06 PM

Answers

  • Verify your SPCalendarView-based webpart is not the culprit.  Change it back to not use CUSTOMID anymore.  Update the SPListItem, and then hover over the next item you want to modify.  Verify the URL.  Also, you are editing via the webpart, so it is possible your webpart is the problem here.  Debug your webpart to see where it has the problem that sends you to the error message within your code.
    Saturday, July 21, 2007 7:49 AM