You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm re-evaluating WiseJ post full-release and currently very impressed with how the platform has progressed since Beta.
It would help me if you could suggest the best approach to developing a custom control that has high drawing frequency.
The control in question is one we have developed ourselves as a .NET control. It is a time-line bar that smoothly scrolls horizontally with additional zoom in/out. I am currently pondering how one would best convert this for use in WiseJ, obviously the actual GDI logic would probably be identical but:
Drawing code on server-side, sending updates via Json to the canvas widget on the client side.
OR
Drawing code on client-side with config data only passed from server to client.
I am thinking probably the update frequency would prohibit approach [1], but I can't yet prove or disprove this. For [2] I wouldn't know where to start, but I am not afraid of writing the canvas drawing code in Javascript - if this is the best way in the long run.
(I am assuming there is no magic available to convert .NET graphics drawing code into something that would execute on the client-side?)
I do also see these two approaches, both should work really nice with Wisej. Which one to pick is a matter of discussing the pros and cons of each approach. I am not aware of a tool that converts C# to JS as you describe it.
Can you explain a bit further what you mean with "high frequency"? Maybe you can simply give it a try because I suspect that the GDI drawing part will indeed be the same in Wisej. Alternatively, you might want to evaluate D3, which is commonly used for such tasks: https://d3js.org/
Will try. This one was particularly easy. But the integration approach highly depends on how the widget works. The problem is that many third party javascript widgets support only one way options, meaning that if anything changes you need to destroy and recreate the widget. Others support updating only some of the properties. When turning it into an extension (instead of using it directly with Wisej.Web.Widget, as you’d do in an angular or asp.net app) the resulting Wisej control/widget has to be able to update itself dynamically so there is some plumbing work to do.
Is pretty much the type of frequency required, however maybe slightly less than that as most the updates occur because of a mouse drag operation or a mouse zoom in/out operation.
I have tried to build a simple test project to see how fast the WiseJ control paint initiated drawing code operates (over web-sockets). I am running the project under IIS on Windows 10 (although was built using Visual Studio 2017 on Windows 7) and no matter what I try I can't get the 'Application.IsWebSocket' property to become TRUE and the updates are falling-back to using standard HTTP.
I have installed the WebSockets feature on the Windows 10 machine
If you check IsWebSocket when the application is loaded in Program.Main() it will always be false since the first load is always http and the protocol hasn't switched yet. You can check Application.Browser.Features.webSocket to see if the client supports it. In subsequent requests Application.IsWebSocket will return true.
However, not all requests coming in from Wisej are always websocket. Data requests from paged/cached data stores (datagrid, listview, fullcalendar, ...) are all http requests. All image resources and postbacks are http requests since they are managed by the browser. And the UserPaint technique is simply an image request so while processing the Paint event you will always have IsWebSocket = false.
I don't know what kind of update speed you need. User paint may not be the right approach. Wisej also supports canvas (HTML5) drawing (see the ProgressCircle extension. You can also try the Wisej.Web.Canvas control. It's different from user painting, it uses a canvas element on the client and sends actual drawing instructions to the client.
Depending on the complexity of the chart you have created, a third option would be to write client side html canvas or svg drawing and get the data from wisej, as I did in the smoothie example (the data is coming from the server). As Thomas suggested, there are many javascript libraries that could help with the low level svg or canvas drawing, animation, zooming, etc. Wisej can turn any of those into a server side component.
I have now run "IsWebSocket" on a button press rather than in the Load and is it returning True.
I have incorporated the ProgressCircle example code and that is another interesting method, so thanks for mentioning that. Just one question, should the canvas updates come via web-sockets now that it appears that web-sockets are enabled? It appears to be updating via post-backs.
We have in the past developed full javascript client-side "controls" using DuoCode (http://duoco.de/) and I'm thinking that there may be a synergy here in that the drawing code (control) could be developed in DuoCode and somehow integrated with WiseJ. With the data structures simply passed from the server.
Thanks for your help so far, I will continue to experiment.
Very interesting. I'll take a look into DuoCode for sure.
The Canvas control has a LiveUpdate property, when set to true, all canvas calls are pushed to the client. Otherwise it collects the calls into a list and sends them back when the canvas widget "asks" for an update. Usually when the widget asks for a set of records we use http because we can match request/response and process the incoming data.
So the trade off in the Canvas control is to either update the widget on each canvas instructions, or updated it all at once at the end of the processing cycle.
Try also the BackgroundTasks example . It uses 3 Canvas controls to draw the lines as they are sorted in background tasks.
Using the examples and extension code I've recently managed to wrap one of our custom streaming media players in a WiseJ widget (the code is standard javascript).
This works very well, and I think the process for the high drawing frequency widget would probably be to convert the existing WinForms .NET drawing code from C# into client-side javascript and then wrap that in a WiseJ widget. I'm now pretty confident this would work.
Just one minor niggle... (hardly)
The example way to wrap Widget events seem to be to use C# 6.0 features, including nameof(). Is there an pre-6.0 C# pattern that could work? (for example if using WiseJ on Visual Studio 2012)?
Activity
itg-assistant commentedon Jun 12, 2026
Thomas (ITG) answered 2017-03-18 14:39:46 UTC
Hi Mark,
thanks for your feedback. ;-)
I do also see these two approaches, both should work really nice with Wisej. Which one to pick is a matter of discussing the pros and cons of each approach. I am not aware of a tool that converts C# to JS as you describe it.
Can you explain a bit further what you mean with "high frequency"? Maybe you can simply give it a try because I suspect that the GDI drawing part will indeed be the same in Wisej. Alternatively, you might want to evaluate D3, which is commonly used for such tasks:
https://d3js.org/
Best wishes
Thomas
itg-assistant commentedon Jun 12, 2026
Luca answered 2017-03-18 19:50:22 UTC
Something like this?
http://demo.wisej.com/smoothie
Uses this:
http://smoothiecharts.org/
Will probably turn it into an extension.
itg-assistant commentedon Jun 12, 2026
Cristian Zerbinati answered 2017-03-19 22:02:37 UTC
Luca it would be cool if you turn this in extension!
it is possible to have a tutorial how do you have create this demo using this external js?
thanks
Cristian
itg-assistant commentedon Jun 12, 2026
Luca answered 2017-03-20 15:32:57 UTC
Will try. This one was particularly easy. But the integration approach highly depends on how the widget works. The problem is that many third party javascript widgets support only one way options, meaning that if anything changes you need to destroy and recreate the widget. Others support updating only some of the properties. When turning it into an extension (instead of using it directly with Wisej.Web.Widget, as you’d do in an angular or asp.net app) the resulting Wisej control/widget has to be able to update itself dynamically so there is some plumbing work to do.
itg-assistant commentedon Jun 12, 2026
Mark McCormack answered 2017-03-21 14:10:00 UTC
Hi Thomas/Luca,
With regards to the required update frequency, yes the demo at:
http://demo.wisej.com/smoothie
Is pretty much the type of frequency required, however maybe slightly less than that as most the updates occur because of a mouse drag operation or a mouse zoom in/out operation.
I have tried to build a simple test project to see how fast the WiseJ control paint initiated drawing code operates (over web-sockets). I am running the project under IIS on Windows 10 (although was built using Visual Studio 2017 on Windows 7) and no matter what I try I can't get the 'Application.IsWebSocket' property to become TRUE and the updates are falling-back to using standard HTTP.
I have installed the WebSockets feature on the Windows 10 machine
I have attempted this https://www.iis.net/configreference/system.webserver/websocket
Can you give me any other ideas what to try?
Regards
Mark
itg-assistant commentedon Jun 12, 2026
Luca answered 2017-03-21 14:23:09 UTC
Hi Mark,
If you check IsWebSocket when the application is loaded in Program.Main() it will always be false since the first load is always http and the protocol hasn't switched yet. You can check Application.Browser.Features.webSocket to see if the client supports it. In subsequent requests Application.IsWebSocket will return true.
However, not all requests coming in from Wisej are always websocket. Data requests from paged/cached data stores (datagrid, listview, fullcalendar, ...) are all http requests. All image resources and postbacks are http requests since they are managed by the browser. And the UserPaint technique is simply an image request so while processing the Paint event you will always have IsWebSocket = false.
I don't know what kind of update speed you need. User paint may not be the right approach. Wisej also supports canvas (HTML5) drawing (see the ProgressCircle extension. You can also try the Wisej.Web.Canvas control. It's different from user painting, it uses a canvas element on the client and sends actual drawing instructions to the client.
Depending on the complexity of the chart you have created, a third option would be to write client side html canvas or svg drawing and get the data from wisej, as I did in the smoothie example (the data is coming from the server). As Thomas suggested, there are many javascript libraries that could help with the low level svg or canvas drawing, animation, zooming, etc. Wisej can turn any of those into a server side component.
HTH
Best,
Luca
itg-assistant commentedon Jun 12, 2026
Mark McCormack answered 2017-03-21 14:58:00 UTC
Hi Luca,
I have now run "IsWebSocket" on a button press rather than in the Load and is it returning True.
I have incorporated the ProgressCircle example code and that is another interesting method, so thanks for mentioning that. Just one question, should the canvas updates come via web-sockets now that it appears that web-sockets are enabled? It appears to be updating via post-backs.
We have in the past developed full javascript client-side "controls" using DuoCode (http://duoco.de/) and I'm thinking that there may be a synergy here in that the drawing code (control) could be developed in DuoCode and somehow integrated with WiseJ. With the data structures simply passed from the server.
Thanks for your help so far, I will continue to experiment.
Mark
itg-assistant commentedon Jun 12, 2026
Luca answered 2017-03-21 15:13:42 UTC
Very interesting. I'll take a look into DuoCode for sure.
The Canvas control has a LiveUpdate property, when set to true, all canvas calls are pushed to the client. Otherwise it collects the calls into a list and sends them back when the canvas widget "asks" for an update. Usually when the widget asks for a set of records we use http because we can match request/response and process the incoming data.
So the trade off in the Canvas control is to either update the widget on each canvas instructions, or updated it all at once at the end of the processing cycle.
Try also the BackgroundTasks example . It uses 3 Canvas controls to draw the lines as they are sorted in background tasks.
/Luca
itg-assistant commentedon Jun 12, 2026
Mark Reed answered 2017-04-10 15:40:32 UTC
Also you could look at Bridge.net since it is completely open source C# => JS transpiler that might make for some really great synergy.
itg-assistant commentedon Jun 12, 2026
Mark McCormack answered 2017-07-26 14:44:00 UTC
Just thought I'd keep the thread up to date.
Using the examples and extension code I've recently managed to wrap one of our custom streaming media players in a WiseJ widget (the code is standard javascript).
This works very well, and I think the process for the high drawing frequency widget would probably be to convert the existing WinForms .NET drawing code from C# into client-side javascript and then wrap that in a WiseJ widget. I'm now pretty confident this would work.
Just one minor niggle... (hardly)
The example way to wrap Widget events seem to be to use C# 6.0 features, including nameof(). Is there an pre-6.0 C# pattern that could work? (for example if using WiseJ on Visual Studio 2012)?
Mark
itg-assistant commentedon Jun 12, 2026
Frank (ITG) answered 2017-07-26 17:20:42 UTC
Thanks for your update Mark !
To use C# 6 with Visual Studio 2012 or 2013 you can take a look here: http://alextselevich.com/2015/08/using-c-6-0-in-visual-studio-2012-and-2013/
Hope that helps.
Best regards
Frank