I’m trying to go through the exercise mentioned in another thread of converting a Visual Webgui solution to Wisej. The change of namespaces and references is the easy part. Wrapped third party controls (like CrystalReportViewer, DayPilot Calendar …) and customized own UserControls implementing VWG Controls are the bigger problem. Also the conversion for menus/toolstrips etc is not that straightforward.
During this exercise I came across some missing items which are listed below:
You gave me lots of stuff to write. 🙂 Sorry for the long reply, but these are important questions.
We tried to be as close as possible to winforms for the standard functionality without replicating the obsolete
properties and features and to add a lot of new web-html5 features as integrated and seamless as possible.
Confession – just between us:
As I wrote to some beta subscribers with knowledge of VWG privately, we were not ready to start the beta and needed 1 or 2 more months. We had to speed it up because if Reddo/Gizmox rush shutdown that was sent out to everyone, including our customers. Having said that, I’m actually very happy that we did since Wisej core has been more than ready and solid for a long time (it has been about 1.5 years of development so far – mostly on the core engine).
1. Form.ShowPopup is missing, although there is a FormShowType.AsPopup in the enumeration
We don’t have the FormShowType enumeration? ShowPopup was something added by gizmox to handle popups like the combo dropdown and it’s not compatible with a form in my view.
Please let me know if this is what you meant. I will add the Popup control to the extensions list nevertheless but I may need some input as the functionality from you.
2. How is DataGridView paging handled? How do we calculate items per page?
Our datagrid is fully virtual. There is no paging. The internal rendering code only creates the dom elements that are visible, making it very fast and not clogging the browser. The data store component fetches, caches, discards pages dynamically as you scroll. We tested the widget with 10M rows without any loss of performance.
Paging is a source of problems to: a) fill the page when the grid is resized, b) page the pager…, c) update the pager when the size of the page changes because of a resize, d) and you still need to scroll the rows even when paging. In many cases you end up with an half empty page while there are more rows in the next page.
You can see the rows using F12 in chrome and see that only the visible portion is actually creates in the dom. The requests for data as async using http(s) and compressed. The server side only returns the portion of data requested and only the styles and data that is actually present/changed.
Incidentally, the same data store is used for the ListBox (not the ComboBox), allowing it to handle unlimited items.
3. In Treeview DragDrop there is nothing like GetNode(x, y)
I have to look into the full drag drop implementation of the treeview. It should/will behave like winforms.
4. In Treeview there is no toggling for checkbox visibility at node level
We can add it, it’s present in the client side. The TreeNode on Wisej can actually show 3 icons: open/close, checkbox, state.
5. MonthCalendar is missing a Value or Date property
MonthCalendar is not fully implemented. It should show in the toolbox, probably a mistake.
6. There is no ContextMenu.Hide method
Context menus don’t have the hide method since once shown they have the focus and anything that changes that, or a selection, will close the context menu. The only way to call Hide() would be from a different thread but I don’t see why. In any case, we can add it if needed.
7. No Separator item for contextmenu (and for menu for that matter)
The separator is a MenuItem with text = “-“. Should work, I hope, will test again.
8. LinkLabel has no Url property
The LinkLabel doesn’t navigate to a URL. For that you can use any label or text with <a> in it. The LinkLabel functionality is similar to winforms LinkLabel, where either the whole text or a portion of the text is a link and it triggers the LinkClicked event carrying the text that was clicked. This way the app can handle links even though it’s not navigating anywhere, being a single page app, giving the impression of navigation. The app could handle to LinkClicked calling Application.Navigate() and navigate to a different URL if needed. If the text in LinkLabel has multiple links (multiple <a> defined
in the Text – not using LinkArea) then LinkClicked will specify the actual clicked text.
9. There is no ToolStrip control (there is a ToolStripItemDisplayStyle enumeration)
Yep, the ToolStrip system is not implemented (should be listed in the beta info page). It’s a large subsystem of components that we will implement fully and with new web specific functionality. I’m not sure it will be in the first release though. There are several enumerations that are not used, we didn’t clean up the code for unused stuff yet, until we draw a final line on what will make it the first release.
Thank you for the feedback!
The six months beta was a safe time period, because of the sudden acceleration forced by the reddo/gizmox shutdown. I’m very hopeful that we’ll be able to wrap up RC1 by September/October.
Drag&drop in wisej works the same as in winforms and it’s quite easy to use. The only additional property we have is AllowDrag. Other than that, all effects and events work the same. We can even handle external drops. The external drags (dragging out of the browser) is disabled for now since it’s very specific to chrome.
About binding, we can make any property bindable just by adding the [Bindable] attribute. It becomes a bit more complicated when it’s a complex set of objects (like a row in a datagrid). To make the menu bindable I’d need to understand the actual functionality. If you send me a test/example app and a description of how you would like to data bind the menu I will certainly do my best to add it.
Thanks for your thorough explanations Luca.
I don’t know very much about the inner workings of Wisej. I suppose that’s what you mean by “Wisej core”. All I can say is that all the issues I saw or read about, are UI/behavioural issues. You guys solved those issues very quickly. I doubt you could solve them so easily if they were due to some flaws on the underlying core.
A few days ago I was telling someone I don’t understand why you need 6 months for beta tests, since I can see a very fast progress and I get the feeling that Wisej is almost ready for production. This discussion shed some light on how much needs to be done before going into production.
This discussion also resulted in some strong statements about the goals and directions of Wisej: it’s the first time I read loud and clear that Wisej goal is – and allow me to repeat – “to be as close as possible to winforms for the standard functionality without replicating the obsolete properties and features and to add a lot of new web-html5 features as integrated and seamless as possible”. This means that where VWG diverges from Windows Forms, Wisej will stick to the Windows Forms base line and doesn’t commit to reproduce VWG innovations. I don’t say this as a criticism; I think it’s important to know where we are heading and I don’t necessarily agree with or need VWG innovations.
So, besides the core Windows Forms controls, there are a lot of extra features coming our way: real time web applications using WebSockets, rich variety of open source extensions, small but very very useful features like easily dropping files on any Wisej control and others we we will discover in the next few months.
Some final comments:
First of all thank you very much for your detailed and long reply, I appreciate you take so much time to reply, while you are, obviously, very busy with other stuff.
You are right about ToolStrip and MonthCalendar being listed in the still missing controls, I had just missed this list in the beta info page. As I said, I tried a conversion of a VWG project, so whatever I had there I tried to convert to Wisej. Even the still missing ones!
I understand the general approach, i.e. keeping the framework close to winforms. Unfortunately, I have never been a WinForm programmer, I moved directly from VB6 to VWG, so my “knowledge” of WinForms comes from VWG and sometimes I assume (wrongly) that what was present in VWG is also present in WinForms.
So, I will try to continue with the items available in the Toolbox! Although I never liked the …Designer.cs files, I think too much is going on there which we do not control, and I prefer to construct my page in the constructor code.