Seven Steps to Improving Your VB Code
-
Yes it was! It started as a VB6 Project. A genius programmer (not me;)) wrote the entire VB code. If someone wants to learn about "Program into your language not program in your language", his VB6 code is a great example. Later it fell in my hands to redesign the UI. I started with CodeJock MFC controls as it gave lot of rich features. However it was not wise to rewrite the entire VB code and port it over to C++. At that time .NET was already out and I was not impressed with Winforms so decided to have a wait and watch policy to see what happens in the UI world. So I decided to do re-use them in MFC as ActiveX controls. The policy was to write new things in C++. Some stuff needed to be modified in VB to change look and feel (as VB tabs did not look nice to sales people), so I developed the tab control in ATL/WTL as VB could host only activeX controls. That being done majority about 40% of the app code was in VB6 and 60% in MFC. The main reason to move to MFC was to allow the application to have some advanced capabilities like in-built HTML form designer which will allow end-users to design their own custom UIs easily which will work both on web and on the desktop. In 2 versions, VB6 was totally unsupported so the phase out VB6 code started. It was decided to use the .NET WInforms DataGridView to replace some of the grid functionality only in the most crucial screen which was a table editing screen. We started hosting .NET control as an ActiveX control it worked but later on figured out that it works well if there is a UserControl which hosts the DataGridViewControl (databinding did not work if the DatagridView was not hosted in a UserControl). We also ended up using C++/CLI to make everything work well in MFC application. Now C++/CLI stinks for any use apart from using it as a thunk layer. So majority of the code written to support the DataGridView (in virtual mode) was written in C#. Also not (shown in the screenshot) we had a property grid for HTML designer which also is the .NET property grid. To support the property grid there was lot of C# code written as property grid associates with .NET objects better. Anyway the lessons learned from this project will span multiple articles but probably it will not be useful to anyone. The main idea was always to bring something quick into production while keeping with technologies, rewriting code especially well tested code is not always the best way to do that. Now that WPF has come out the new direction of new UI development in the app is to be re-thought.
Rama Krishna Vavilala wrote:
databinding did not work if the DatagridView was not hosted in a UserControl
Wierd. I wonder why not!
Rama Krishna Vavilala wrote:
Now C++/CLI stinks for any use apart from using it as a thunk layer.
That's been my opinion all along! I'm glad someone else feels that way. :)
Rama Krishna Vavilala wrote:
rewriting code especially well tested code is not always the best way to do that.
A very good point. I'm sticking that in my Wisdom category on my blog. :) Marc
-
Rama Krishna Vavilala wrote:
databinding did not work if the DatagridView was not hosted in a UserControl
Wierd. I wonder why not!
Rama Krishna Vavilala wrote:
Now C++/CLI stinks for any use apart from using it as a thunk layer.
That's been my opinion all along! I'm glad someone else feels that way. :)
Rama Krishna Vavilala wrote:
rewriting code especially well tested code is not always the best way to do that.
A very good point. I'm sticking that in my Wisdom category on my blog. :) Marc
Marc Clifton wrote:
Wierd. I wonder why not!
DataBinding relies on a BindingContext. Only container controls like forms or UserControl provide a BindingContext. So if you host a control outside of a UserControl or Form it will not have a BindingContext and so it will not work.
Co-Author ASP.NET AJAX in Action