Sub: Vb 6.0 to VB.Net conversion problem w.r.t FormActivated event
We are converting a Visual Basic 6.0 application to vb.net 2008 and are having an issue, while executing the code under “form activated event”. There is a difference in behavior between form.activate in Visual Basic 6.0 and form.activated in vb.net. In Visual Basic 6.0, the Activate event was raised only when switching between forms in the application; in Visual Basic .NET, the Activated event also is raised in case of showing messagebox and when switching from other applications.(by msdn)
In vb6 application the purpose to use form activate event is, to execute some code when forms become active. In our application forms are loaded, hide and show in different flows. So whenever this form is shown from hide state or any of its child form return focus to it, we need to reflect different changes in the application to the specific form controls.
* For example user changes its application preferred language.
* As the application is huge, so shifting logic to other place with respect to the current scenario might solve the problem for the current form but then I have to re think it for all other forms (which is very hectic and more or less not feasible).
In the migration process it is required to make as little changes in the existing code execution hierarchy. So we need a similar behavior like form.activate in vb6.0 with some other event or restrict some functionality of Activated event in vb.net.
What do you have in the old Form_Active that needs to be run?
I don't answer coding questions via PM or Email. Please post a thread in the appropriate forum section.
Please use [Code]your code goes in here[/Code] tags when posting code.
Before posting your question, did you look here
Got a question on Linux? Visit our Linux sister site.
Modifications Required For VB6 Apps To Work On Vista
In my experience, and in the experience of many of the programmers I meet (as a Visual Basic trainer, I meet more than a few), converting an application from VB6 to VB.NET is a very bad idea, specially if you have a big complex application.
To many things behave differently between the 2 languages. Don't be fouled by the VB label. Under a similar syntax, these are 2 very differents beasts. The problem you have encountered is probably only the first one in a long sequence.
The code generated by the conversion is not good .NET code and brings a loss of performance compared to the VB6 application, so you gain nothing. It keeps using old technologies such as the classic ADO instead of using the newer technologies ADO.NET. It does not use any of the enhancements you can find in normal VB.NET code.
It will be a nightmare to maintain because it is not standard .NET code. For instance, it creates 2 variables for each form in order to simulate the way forms were working in VB6. It makes a heavy use of the Microsoft.VisualBasic.Compatibility library. Nobody would code like that in .NET.
Almost every conversion project I have seen was scrapped after a few weeks or a few months because too many subtil bugs surfaced continually while the application was used.
The conversions that had some success were projects in which the VB6 application was created with an object oriented design, where most of the code was in dlls and very few code was in the application (the forms) itself. In such cases, it was quite easy to recreate the interface in .NET and while still using the old VB6 dlls. Then, as needs changed, the dlls were slowly, one by one, recreated in .NET.
The situation is quite clear for anybody who has been working professionnally in both VB6 and VB.NET: old VB6 applications are kept in VB6 and maintained in VB6, new applications are written in VB.NET.
If you really want the old application to go .NET, for the more advanced features, stability and security, or because you want to have it in a technology that will still be supported and work in new versions of Windows in a few years from now, you have to rewrite the application in VB.NET.
Thank for your detailed reply, i understand the fact you mentioned. Both the languages are different but I think this migration thing can be handled with extra work. Currently my problem is to make vb.net activated event a bit like vb 6.0 activate event. I need to solve that problem either by overriding or some other means, i am unable to find at the moment, for which i am here for help.
In the previous application multiple forms can be opened in MDI environment. All forms have life time of the application so if a form activate(s) in the application it will reflects user changes (units, language etc.) on its controls. This includes focus from other forms except messagebox dialogs. So i need a generic kind of solution i.e. to override an event definition or behavior for my entire project. I don't know how this can be achieved, but on the other hand i find different .net winform UI components which provide such altered/modified behavior in windows form events. So i know this is possible but don't know the solution. Please share any kind of "event behavior" altering material.
You cannot override an event definition. You can only override the method that raise the event. The methods whose name starts with On... have been designed for that (OnActivated, OnClosing...). You can thus change what happens when the event is triggered, but not change when or how the event is triggered.
So forget about using events to apply new units or languages.
When you see controls that adapt to changes in the culture (date and number formats, language, etc.), they can do it in different ways depending on the exact needs of the application. I suggest that you spend some time studying the System.Globalization namespace, specially the CultureInfo class.
.NET has been designed so that you set the culture when you start your application with something such as the followings:
My.Application.ChangeUICulture("fr-CA")The first one set the culture to the culture defined in the Control Panel, the second one to French. Most methods and controls will automatically adjust to that. This setting is applied when the form is created however. If you change the setting in the middle of the execution, it will apply to newly created forms, but not to already created forms. That is why most applications need to be closed and restarted in order to apply a change in culture.
System.Threading.Thread.CurrentThread.CurrentUICulture = System.Threading.Thread.CurrentThread.CurrentCulture
System.Threading.Thread.CurrentThread.CurrentUICulture = New System.Globalization.CultureInfo("fr")
If you want to be able to change the culture on the fly on a form that has already been created, you will have to implement your own system, because .NET does not provide one.
Since the application is MDI, then it might be very simple.
When a change occcurs that has an impact on all the forms, do not wait for the Activated event to apply the change. Simply loop through the childs and apply the change right away on all the forms, starting with the ActiveMdiChild so that there is a minimal delay for the user.
And I come back to my previous post and one of your comments: "I think this migration thing can be handled with extra work".
I have seen that too many times in the last few years. This almost always finish as scrap after a few weeks or a few months.
When an application has been designed for VB6, the design is flawed in .NET. Converting the code from VB6 to VB.NET needs work but can be done. Converting a design is almost impossible if you stick with the same code base.
.NET has a different way of handing culture, memory management, events, and a few other things. The default variable type in VB6 is the variant, which does not even exist in .NET. These are not simple things that one adjust with a few line of code, these are fundamentals to the way an application works.
I had a students once that felt that moving from COM/ActiveX (VB6) to .NET was aking to moving from MS-DOS to Windows, from a Mac to Windows. He is right.
Your problem with the Activated is just an indication of things to come. You will encounter many more like that. And a lot of the problems do not surface so fast, it often takes months to find out that a subtil change in the way the application behave corrupts some pieces of data.
The bigger the application, the more chances you have of falling into unsolvable design issues. And you are telling us that you have a "huge" application.
Sure, you will eventually be able to make things work "with extra work". But you will end up with a messy application.
I have seen a conversion project once on a big application that was almost working OK after 1 year of work. The application was on average 10% slower than it was in the VB6 version and they had so much problems maintaining the thing that after an extra year they finally decide to rewrite the application from scratch, which took only 6 months.
2 years of painful work plus 6 months to rewrite the application. 6 months would have been enough if they had not held on their thought that they could make it work.
This is quite typical. Rewriting often takes less time than converting. But the result is an application designed and optimized for .NET, not a horse carriage on which you have adapted a GM motor.
By vineeth in forum VB Classic
Last Post: 07-31-2005, 01:43 PM
By Phil Weber in forum .NET
Last Post: 10-01-2003, 01:00 AM
Last Post: 12-11-2002, 06:05 AM
By Thomas Eyde in forum .NET
Last Post: 12-22-2001, 03:13 PM
By Jean-Yves in forum Enterprise
Last Post: 06-01-2000, 01:23 PM
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center