Frank, i will test tomorrow (already late in Greece!) and let you know.
Luca, to make it absolutely clear, if I’m not using the designer but create my controls at runtime, does this mean I do not need even the assembly reference?
Alex
Hi Alex,
If you mean the assembly reference, we can’t remove it since we use the full winforms designer system in Visual Studio (and SharpDevelop), it’s a large beast and instead of writing a crippled one it was much better to reuse what works very well. Wisej controls create a window control when in design mode, that’s how we are able to paint pixel-perfect design surfaces.
Best,
Luca
Tiago,
thanks again for your sample and feedback.
Can you please retest with the latest Wisej build (1.2.9) following Luca´s comments ?
Best regards
Frank
Hi Alex,
thanks again for your valuable input and test case.
We have just uploaded a new beta build #1.2.9 that resolves the binding issues.
Can you please retest and provide us feedback ?
Best regards
Frank
So it was kind of lucky I’m using pages and not forms! 🙂 So, the tabcontrol (tabpages) follow the initial state of their top container, a page in this case. Thanks for your fast response and I appreciate the update!
The Wise.Data is the least problem! The main thing is to remove the System.Windows.Forms dependency. The rest is easy.
Thanks again,
Alex
A new Wisej build (1.2.9) has just been uploaded. It includes the following fixes and enhancements:
| Item | Type | Priority | Severity | Title | Resolution |
| WJ-7314 | Bug | Low | Trivial | Nested SplitContainers don’t remove the border of the parent panel. | Complete |
| WJ-7317 | Enhancement | Low | Trivial | Translate CRLF to BR/ also for buttons and labels. | Complete |
| WJ-7319 | Bug | Medium | Major | Databinding is not triggered when a control loses the focus by tabbing out. | Complete |
| WJ-7322 | Bug | Low | Trivial | Components in the project derived from System.ComponentModel.Component don’t appear in the toolbox. |
Complete |
| WJ-7323 | Bug | Medium | Major | Data bound children of Page and Desktop don’t update their data bound properties the first time the container is shown. |
Complete |
| WJ-7324 | Bug | Low | Trivial | Removing a child panel with tool buttons at design time doesn’t remove the tools from the container. |
Complete |
| WJ-7316 | Bug | Low | Trivial | Selecting event is not fired for TabControl | Complete |
| WJ-7301 | Bug | Medium | Minor | KnobControl is broken, it shows property or method “getFamily” is not supported | Complete |
| WJ-7325 | Bug | Low | Trivial | KnobControl may cause a “double” to “int” exception because of sub-pixel values. | Complete |
| WJ-7313 | Enhancement | Low | Trivial | Resize the icon in a button control to fit the image size set in the theme. | Complete |
| WJ-7318 | Bug | Low | Trivial | ReadOnly TextBox controls still gain the focus. | Won’t Fix |
Hi Alex,
To keep you updated, the binding issue you have reported has been fixed. It was caused by the Page starting at creation with the visible state to true so there was no transition the first time it’s shown. That’s why the tab pages updated the binding after they were hidden/showns. Wisej.Web.Form instead has the right initial state. The same issue was fixed for Wisej.Web.Desktop: the three top level containers.
I can run your sample perfectly now.
The other issue with the namespace is also fixed. Now every reference and every data binding class is under Wisej.Data. The only problem when porting from WinForms is that you can’t replace System.Windows.Forms with Wisej.Web for the data binding classes but you need to change it to Wisej.Data. That’s because Wisej.Data is in Wisej.Core.dll which is shared with the Wisej.Mobile controls.
Frank will update the beta build and the issues list shortly.
Best,
Luca
Hi,
If I may make another observation… as I was trying to find out what could be wrong with the binding, I discovered that in my VWG-converted code the Bindingsource object I had defined wasn’t very clear if they were Windows.Forms.BindingSource or Wisej.Data.Bindingsource. You need to find a way to get rid of the Windows.Forms namespace dependencies.
Best regards,
Alex
Fantastic. Thank you! We should be able to iron out all binding issue within this week.
Luca,
I’m attaching a test project. A page containing a splittcontainer with two textboxes in Panel1 and a TabControl in Panel2. Two tabpages, each with a textbox. All textboxes bound to properties of a simple customer object. When loaded, the two textboxes of Panel1 remain empty. Also empty is the textbox in the visible tab1. If you switch to tab2, you will wee the textbox there filled. By switching back to tab1 you will see the textbox filled too. The textboxes in Panel1 never get filled.
The strangest of all is that if I do the same with a form instead of a Page, the textboxes are filled from the beginning.
HTH,
Alex
Luca, they are databound. And the event I’m using is the tabcontrol.selectedtabchanged which I have seen it fires. The workflow is followed the same way it was followed in VWG from what I’ve seen from debugging. I’ll see what I can do with a test case.
Alex
Are the controls data bound or filled by code? If filled by code, which event do you use to fill the controls in the tab?
Would it be possible to send a tiny test case with a tab control, a couple of tabs and a control in each using the same approach that is not working?
The reference has to be there. We create a real windows control in design mode to have a designable surface to render (paint) the html into. At runtime we don’t create it and use the base winforms ScrollableControl as a POCO component.
I meant the namespace should be removed everywhere. But of course, as you pointed out, if you use those data binding classes it’s not possible until we remove the inheritance that I mentioned before.
Best,
Luca
Hi Luca,
You mean remove the System.Windows.Forms reference from the project? Right now you need it at least for 3 reasons:
I’m used to convert Windows Forms projects to VWG. I prefer to develop on Windows Forms and port it to VWG. The porting is really quite easy. I expect it will be as easy to port to Wisej as it is to port to VWG.
The fix for the DataBinding bug is part of CSLA .NET. This framework’s license changed to MIT early this year so Wisej can re-use the code at will.
Hi Tiago,
The problem is from the base WinForms.Binding. I see the issue you are referring to and will remove the WinForms.Binding completely from the base. It was just convenient/fast to extend. Send me also additional information about the Microsoft bug please, I’d like to fix it in Wisej if possible.
In general, when porting from winforms to wisej, the System.Windows.Forms namespace should be eliminated completely. Our service partner has already developed a tool to seamlessly convert very complex Winforms apps to Web apps with a single click. It has been used already on several projects and not it’s being adapted to Wisej because we were using our framework based on VWG which is now based on Wisej. I can send you a link to a video if you are interested.
Best,
Luca
Hi Mark,
I will answer in two separate posts.
Security is a very important topic especially when dealing with web apps. I’ll cover the most common vulnerabilities, but please send me anything you can think off that may be a threat.
HTML/Script injection
One of the biggest difference between a traditional ASP.NET/MVC app and a Single Page App (SPA) is that there isn’t any HTML built on the server and sent back to the client. Everything happens on the single page manipulating the DOM. This is true for all (most actually – VWG was recreating the DOM in most cases instead of manipulating it) SPAs. This removes any risk on code injection since scripts are not executed when using the DOM (innerHTML to be specific).
Session Hijacking
This is a common problem for all web apps – especially with ASP.NET/MVC, PHP, JSP – that maintain a session which requires either a session cookie or an id in the URL. If someone gets hold of a live session id they can add it to the URL or set it in a cookie and access a live session. Wisej supports both cookies and cookieless sessions. In order to prevent session hijacking Wisej checks the clien fingerprint on every request. If it doesn’t match it will assume it’s a new client and it will create a new session. This avoids also the potential problem of stale sessions. You can see the client fingerprint using Application.ClientFingerprint. The best way to also protect against a potential session hijacking is to enable SLL. Wisej can force the app to use SSL by setting “forceSecureConnection”: true in the application’s json configuration file.
DoS Attacks
We didn’t include code to protect against denial of service attacks because it would still be too late once it reaches the http handler. We can ameliorate a DoS event but it doesn’t help much at that level since IIS has already used a thread. If using the async IHttpHandler you can block the request without using a thread but then all the DoS requests would still bring down the legitimate requests. DoS are better handled at the OS level before they reach the web server, whether it’s apache or IIS. There are also several HttpHandler samples around, but I don’t think they are effective at all against a DoS attack.
Authentication
Wisej can authenticate users however your app wants to. Since nothing is shown to the user or it’s even present on the browser unless your app has created and shown the page, form, control, etc. You can authenticate, disable, hide, show anything depending on the roles, permissions, etc.
Sensitive Data, Keys, Code, Tokens
Traditional HTML assemblage systems always end up with a mix of javascript on the client, callbacks, postbacks, services, api keys, and so on. A potential intruder can simply look at the code and page and may be able to acquire sensitive info. The same vulnerability is actually much bigger on SPAs systems like ExtJS, or even standalone qooxdoo, dojo, or any javascript only framework. Since you are forced to put some code on the client and some on the server mostly as services and open end points.
With Wisej there is absolutely nothing by design from you app on the client (unless you put it there). It only runs the widget library with the only task to display information received by the server and send events back. Everything coming from the server is a simple, readable, JSON set of properties that describe the state of each widget (i.e. {“id”: “id_45”, “width”:34, “text”:”Hello”}). Nothing can be gained by looking at the communication since it’s all data used to update the screen anyway.
This will be a topic in the docs as well.
/Luca
Thanks, Tiago
I have logged WJ-7135 for missing tree view methods.
Best regards
Frank
Hi Frank,
It is now fixed.
Regards,
Cris
Hi Frank,
It is now fixed. If you discuss tab handling in the future, you may consider whether a new tab is placed before or after the current tab, always at the end or beginning of the Mdi tabs.
Just my two cents.
Regards,
Cris
Hi Frank,
Confirmed working.
Regards,
Cris
