Had the same problem, the workaround I chose was to do a refresh directly from the event handler using the default asp.net PreRender event. It's ugly, and should not be necessary, but I haven't found any way around doing it like this.

In my Event handler I have this as the last few lines:

            if (((Page)HttpContext.Current.Handler).Items.Contains("hotSpotNodeUrl"))
                ((Page)HttpContext.Current.Handler).Items.Remove("hotSpotNodeUrl");

            ((Page)HttpContext.Current.Handler).Items.Add("hotSpotNodeUrl", HttpContext.Current.Request.Url.ToString());
            ((Page)HttpContext.Current.Handler).PreRender += HotSpotPreRender;

I save the current URL in the variable, then add that data to a PreRender eventhandler.

And the prerender looks like this:

        private static void HotSpotPreRender(object sender, EventArgs e)
        {
            if (((Page)HttpContext.Current.Handler).Items.Contains("hotSpotNodeUrl") && !string.IsNullOrEmpty((string)((Page)HttpContext.Current.Handler).Items["hotSpotNodeUrl"]))
                HttpContext.Current.Response.Redirect((string)((Page)HttpContext.Current.Handler).Items["hotSpotNodeUrl"]);
        }

Hope this helps.

Hmm! It seems like a bit of a kludge - no offence meant. I appreciate the response, but maybe it will push me to look a little more in the source code to see what I can do.

Without my event, the datatypes manage to obtain their values, save them to the properties and then display themselves again.

They clearly are not loading the data back from the database, it must be a cache of some sorts, whether XML, viewstate or whatever. Therefore I must need to somehow update that cache.

I've noted the issue in my todo list and hopefully at the end of this project I can come back to it. For now I'll just have to write a note for the user until I can correct it.

A sincere thanks for going to the effort of the response. It is much appreciated.

Cheers

Steve

Let me explain why this is necessary. The actual save is not being done from within the .Save() method, but when you update a property (say: Member.getProperty("expiration") = tomorrow;).

As the updating of the property through the BeforeSave/AfterSave events is happing DURING the page load, Umbraco / .net still has the old values in memory. Only when you refresh the page, it gets the new values.

The BeforeSave event looks like this:

        public override void Save()
        {
            SaveEventArgs e = new SaveEventArgs();
            FireBeforeSave(e);

            if (!e.Cancel)
            {
                //Stub...

                FireAfterSave(e);
            }
        }

Hi Sebastian,

You are right. I've been thinking about this for a while, plus a similar problem came up with some cross value setting datatypes that I was writing.

I'm currently creating an Extranet for a client and needed media file controls, but that saved to the database in an encrypted form. All done and dusted, but I also created data types that show the file type and the file size. In this instance the main file upload control checks if the document has the appropriate properties for the other datatypes and if so, sets them.

So again we come to the same problem as above, in that these other datatypes pick up their value at Page_Load time and thus don't appear to be set with a new value until the page is refreshed.

In this instance, since I had total control I set the passive datatypes to go and fetch their property values again at PreRender time and that solved the problem nicely.

It did make me reflect again on this problem and realise that you are right and that there is not much I can do about it apart from doing a refresh, or using my own data type that checks its own value again at PreRender time. What a pity that they don't.

In this instance I don't want to rewrite the datepicker control, so I've going to have to go with your refresh route.

Perhaps we can put some pressure on to rewrite the datatype interface for V5 to ensure value refeshes at PreRender.

Anyway, once again, thanks for your help - I really enjoy scratching around at the underbelly of Umbraco and seeing where it can be pushed. It just shows what a good framework it is that we can normally code round issues.

Hi Sebastian,

Thanks for your help here. This task has come to the top of my queue now and your solution worked perfectly.

As you say, it is an unfortunate and ugly work around, but in fact, from a user perspective it is not noticeable and that is the main point at the end of the day, so I'm very happy with it.

Once again - thanks a lot. I'd vote you up, but I'm lacking on the Karma side - one day.

Cheers

Steve

Yes, I can do solved it turns out. So I have marked it as such.

Once again, thanks for your help.

Is there any codeplex item for me to vote on to get this mended in v5 ?

V5 will be completely new code and will most likely not rely on any of the existing event handlers. The core team is aware of this situation and will design a better api around V5.

The last post to this topic was over a year ago. Have you folks discovered any different way to approach this problem, or is the answer still the same?

Many years later this is still a problem. There is this issue in the issue tracker: http://issues.umbraco.org/issue/U4-3004

is working on a reply...