All Answers

Hi,

I just noted by chance that there is a new update (1.2.5) available. Could please keep us posted about the changes and additions?

Thanks!

Thanks, Tiago.

I have logged WJ-7293 for this issue.

Best regards
Frank

Hi Luca,

I have to add uc.BringToFront() to make it worked. Another option is to put another panel, dock it to Fill and make it as a container of the UserControl.

Thanks

Cris

It works here. Which means that you probably don’t have WebSocket enabled. In Chrome use F12 and Network and you will see that it never switches to WebSocket.

Apparently IIS 8 Express supports WebSocket but only from Windows 8 up: http://www.iis.net/learn/extensions/introduction-to-iis-express/iis-80-express-readme

Without WebSocket you can still update the client asynchronously but you need a request (any request) to be started from the client. If you add a Wisej Timer component to the form it will fire an event every interval and cause a client update. The thread code above will still work but the client will be updated at the timer interval.

Forgot: you can also check using

Application.IsWebSocket

Hi Nic,

I have just tried the sample you attached and it works fine here.

Did you try with the latest Wisej build ?

Best regards
Frank

Hi Luca,

Thanks for the explanation and the sample but my test program (attached) stubbornly refuses to change the colour of my panel. Any chance you can tell me what I am doing wrong?

TIA

Nic

Hi Nic,

The background task sample uses Application.StartTask which internally restores the context before calling the task method. To use Application.Update() in a different thread other than the “request thread” (which has the session restored, including a reference to the ResponseManager connected to the WebSocket) you have to save the context and then restore it in the new thread.

The easiest way is to use a closure, change your  test code like this:

var context = Application.Context;
timer.Elapsed += (s, e) => {

  // restore the context on the current thread.
  using (new Wisej.Base.ApplicationContext(context))
  {
    // here you can call any other method, or place the code to run in the new thread, or a thread loop.

    // to test it I did this:
    Application.OpenForms[0].Text = Thread.CurrentThread.ManagedThreadId.ToString();

    // this works now because the context has been restored by the using statement.
    Application.Update();
  }
}

When running in the main (or request thread) you can call Application.Update() at any time and force the client to update. The downside of having long running operations in the request thread is that Wisej on the client side will automatically show a mask and a loading gif covering the control that fired the event and that is not receiving an answer within a certain amount of time.

HTH

Best,

Luca

I must confess I didn’t try to convert a VWG project to Wisej since all my projects depend on MvvmFx. Wisej isn’t stable enough to port this library to Wisej so I must wait.

Anyway, I guess you also have to remove the ProjectTypeGuids on the project file.

Hi all,

I agree that the NullableValue is the best way to go.

regards,

Alex

As per release 1.2.5, when I click the column header the error doesn’t show but:

1. the grid is refreshed
2. an sort symbol (arrow) shows on the column’s header

If the data in the gris isn’t sortable, clicking the column’s header should have no effect at all.

The “NullableValue” Property is a good idea and probably the best solution for the DateTime Picker.

Add a new bindable property “NullableValue” looks like the best solution, as it doesn’t compromise the core functionality and supports the null concept. While we are talking about “bindable” properties, I’d like to see components, like MenuItem etc. to implement IBindableComponent, i.e. to be “bindable”.

Hi Luca,

I have done exactly that in my custom DateTimePicker UserControl, i.e. I have it return a DateTime? value and binding works correctly. But I wouldn’t like to test an experimental build now, I think we should keep playing with one bet product at the moment and not “deviate” to different versions.

However, I don’t see why not make your controls return nullable types if this is possible. What is the opinion of other beta testers?

Best regards,

Alex

The problem with null dates and numbers is that Microsoft left them out when they designed .NET from the start. DateTime and Decimal don’t have an IsNull property and cannot be null. In addition, ADO.NET expects and returns DBNull.Value when the db field is null.

We have a similar issue in our other .NET framework and we added IsNull and UseMinValueAsNull and we have an IDbValue interface for binding on our custom types. However those solutions cannot be applied to Wisej.

We could change the Value type of DateTimePicker and NumericUpDown to DateTime? and Decimal? nullable types. That would allow the control to return null when empty. I’m not sure how a database bound data source would react, need to test this.

Would you like to receive an experimental build with DateTime? and Decimal? Value properties in DateTimePicker and NumericUpDown and give it a try on your end?

Hi,

1. Forget what I said for Sundays, I was obviously blinded ! I was clicking on the left column, obviously the week counter! Sorry for the false alarm.
2. If I understand correctly, if DateTimePicker interprets empty value as DateTime.MinValue, this means, I suppose, that when the control is bound to a datasource, it will propagate this DateTime.MinValue to the database. Instead, I would like to send Null to the database. May be other people can express their opinions too.

Thanks for your answers.

Best regards,

Alex