Seven Steps to Improving Your VB Code
-
Rama Krishna Vavilala wrote:
Ok Let's play the game:
I'm in. The UI is built on 3rd party components rendering the application development platform irrelevant to this discussion.
There is only 1 third part component (CodeJock) rest of the stuff is built in house or uses standard controls.
Co-Author ASP.NET AJAX in Action
-
There is only 1 third part component (CodeJock) rest of the stuff is built in house or uses standard controls.
Co-Author ASP.NET AJAX in Action
-
Those are good seven steps for any language, not just VB! Though #1 (normalize the UI) is amusing because I can always tell a VB app because of the funky colors, large fonts, and odd UI. Marc
Marc Clifton wrote:
I can always tell a VB app because of the...
I thought you were going to say "stench." BDF
-
led mike wrote:
So that means that C is the old VB right?
Heh, well... i've seen some baaad C code, but it usually takes the form of excessively long functions, lots of global data, unsafe string/memory manipulation, and bizarre control flow. VB's "everything attached to a form or other bit of UI with arbitrary datatypes and type conversions, with a gratuitous 3rd-party control thrown in to do something simple like sort" isn't necessarily worse, just distinctive. Of course, we all know that bad code can be written in any language. But just as your country of origin largely determines whether you put ketchup or brown sauce on your hotdog or meat pie, the language you use does have an effect on which mistakes you're likely to make. ;)
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
Shog9 wrote:
VB's "everything attached to a form
Only because those guys that did...
Shog9 wrote:
excessively long functions, lots of global data, unsafe string/memory manipulation, and bizarre control flow.
.... didn't have forms! :laugh::laugh::laugh: Your description is fairly close to what I am dealing with. They also abuse the heap and of course pointers. And the bizzarre control flow/state management results in thread affinity rendering the entire body of work useless in todays world.
-
Ok Let's play the game: VB or .NET or Win Forms or WTL or MFC? The UI is at the following location: Screenshot
Co-Author ASP.NET AJAX in Action
A VB scaffolding around WTL + MFC code?
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
Shog9 wrote:
VB's "everything attached to a form
Only because those guys that did...
Shog9 wrote:
excessively long functions, lots of global data, unsafe string/memory manipulation, and bizarre control flow.
.... didn't have forms! :laugh::laugh::laugh: Your description is fairly close to what I am dealing with. They also abuse the heap and of course pointers. And the bizzarre control flow/state management results in thread affinity rendering the entire body of work useless in todays world.
led mike wrote:
Only because those guys that did... .... didn't have forms!
Yup! ;) Just think what VB code would be like if pointer ops were more obvious in that language...(!)
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
-
Rama Krishna Vavilala wrote:
The correct answer is All of The Above
Nice! That must have been quite interesting to put all together. Marc
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.
-
sort of!
Co-Author ASP.NET AJAX in Action
-
Rama Krishna Vavilala wrote:
VB or .NET or Win Forms or WTL or MFC?
Photoshop? :rolleyes:
Nobody can give you wiser advice than yourself. - Cicero .·´¯`·->ßRÅhmmÃ<-·´¯`·.
Co-Author ASP.NET AJAX in Action
-
Step 1. Dont use it.
Roger Irrelevant "he's completely hatstand"
-
Phil Harding wrote:
Yeah, it seems the same for Delphi too, why is that I wonder
That's a diffent issue than VB's anti-design patterns. With borland tools you have the fact that Borland was convinced they could make better controls than MS, as a result most (all?) of their 'standard' controls are custom not win32 basic constructs. As a result they always function subtlety different than standard.
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
Actually that's not entirely correct. Any of the standard controls like the button, edit box combo box, tree, list view, tabs, progress ctl, status bar, toolbar, coolbar/rebar, etc are in fact MS Common Control with their WndProc wrapped by a custom Borland wnd proc in Object Pascal. Some of the other controls, like the grid control are custom. At least that was true up to version 4 of Delphi. After that I haven't seen the VCL code so I don't know if they changed it.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
Ok Let's play the game: VB or .NET or Win Forms or WTL or MFC? The UI is at the following location: Screenshot
Co-Author ASP.NET AJAX in Action
MS Paint.;P
Deja View - the feeling that you've seen this post before.
-
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
