Question about update

The only reason I can think of is that WebSocket is not on. Even if WebSocket is enabled, when the app is first loaded – this is the first http request that causes Program.Main to be called – it’s not in WebSocket mode and there is no connection yet, so starting a task still works but the push update doesn’t.

Also, when you call action.Invoke() maybe the affected controls were not marked dirty for some reason. One way to check is to verify that the controls that have to be updated on the client are indeed marked dirty: ((IWisejComponent)control).IsDirty.

Let me know.

/Luca

Any reason why this extension wouldn’t work to execute a task and always force a UI update at the end?

public static System.Threading.Tasks.Task StartTask(Action action)
{
return Application.StartTask(() =>
{
try
{
action.Invoke();
}
finally
{
Application.Update(Application.Current);
}
});
}

For Application.Update(IWisejComponent) it doesn’t matter which component. It needs it just to retrieve the session. The Application object itself is a IWisejComponent that you can save using Application.Current and then reuse in an out-of-bound thread to push updates to the client.

Control.Refresh(bool) at runtime is the same as Update(). At design time it forces the update of the non-client areas and refreshes the current selection frame. We use it in design mode when the theme changes or a property that would affect the form title, or a panel title, change since the titles are non-client areas.

Control.Invalidate() is also similar, but it invalidates the cached JSON definition and forces the server to resend the full set of properties back to the client. The client also has a copy of the existing values, so only the different values will be applied (unless the javascript property is implemented using getter/setters).

HTH

/Luca

Sorry another question.

What does control.Refresh() do?

If I do Application.Update the first parameter you pass is a control. Does it matter which control is used if it is just pushing updates?

Form vs Button on a form?

Control.Update() marks only the single control as dirty. To force all children (and children of children) as dirty, use Control.Invalidate(true).

However, when Wisej collects all changes at the end of the request (or when calling Application.Update()) it will diff the changes with the last rendering and will send back to the client only the diff’d changes as a json package. It is usually not necessary to call Update on a control unless a visual property that affects the client has actually changed.

If I did Control.Update on a Panel does it flag all the child controls as dirty as well or would I need to flag them manually?

Control.Update() is used to mark the control as “dirty”. Controls in the “dirty” list are included in the response stream back to the client. You would use it if you add a property or a method to a control subclass and you want Wisej to update the widget on the client when the property is changed or the method called.

Application.Update() pushes all pending updates (dirty controls) to the client without waiting for the response to finish. When you have code in a thread that was not initiated by a client request (out-of-bound) you can use Application.Update() to push the updates to the client.

You can also use Application.Update() at any time while processing a normal request (i.e. a click) to update the client. The parameter is used only to retrieve the context, it doesn’t matter if you use a form or a control, everything that is pending at that point is pushed to the client.

Application.StartTask() is the same as Task.Run() but it restores the context before running the action.

Application.Update(ctrl, ()=>{…}) executes the action and calls Application.Update(). The code in the action block is called after the context has been restored, so you will find the session variables, browser info, cookies, etc.

HTH

/Luca

Or like when would I want to do this.

ctrl.Text = “Test”;
Application.Update(ctrl);

vs

Application.Update(ctrl, () =>
{
ctrl.Text = “Test”;
};

I think it also might because the controls as nested down a few layers of Application.StartTask