COMO ATUALIZA O VB 6 PRA VB .NET
Alguem tem algum link pra ajudar?
até onde eu sei não é possÃvel, [Ô]ATUALIZAR[Ô], do VB6 para o .NET, você simplesmente instala o VB.NET, e pode ficar com o VB6 e o VB.NET instalados.
se ajudar me pontue ae
http://forum.wmonline.com.br/topic/70081-atualizando-do-vb6-para-o-vb-net/
http://forum.wmonline.com.br/topic/70081-atualizando-do-vb6-para-o-vb-net/
Macoratti ajudando nisso tmb:
http://www.macoratti.net/vb6_vbnm.htm
http://www.macoratti.net/vb6_vbnm.htm
Para encurtar a estória, vamos analisar alguns pontos:
1 - A maioria dos programadores que usam VB6, não seguem e na maioria das vezes nem sabem o que é Orientação a Objeto ou POO. Isso faz com que seus programas tenham um nÃvel de acomplamento muito alto. Acoplamento é a dependência entre objetos, um exemplo disso é [Ô]uma tela que faz tudo[Ô] como um cadastro de clientes por exemplo, todo o código necessário para manipular e consultar clientes está no código do form.
2 - O Ãtem acima, é parcialmente culpado pelo próprio VB6 que não possui uma orientação a objeto sólida, encorajando a usar a programação [Ô]procedural[Ô] que por si só, tem um alto nÃvel de acomplamento.
3 - VB.NET não é só [Ô]um upgrade do VB6[Ô], é todo um conjunto de conceitos e paradigmas que devem ser dominados antes de se começar a trabalhar com ele, como a orientação a objeto por exemplo
Com isso temos algumas ponderações a serem feitas:
1 - Qual o tamanho da minha aplicação?
2 - Qual o nÃvel de acomplamento dela?
3 - Quão necessário é que eu faça uma migração?
Se sua aplicação é bem grande e com alto nÃvel de acomplamento, tenho más notÃcias: Vai dar um trabalhão para migrar tudo, tanto que é melhor mesmo reescrever tudo do zero, usando os conceitos que a plataforma .NET oferece(logicamente, dominando-os antes). O Visual Studio tem um [Ô]migrador[Ô], uma ferramentazinha fuleira para a [Ô]migração[Ô] do seu código VB6 para .NET, mas dependendo do nÃvel de acomplamento e tamanho da sua aplicação, você vai levar 3 vezes mais tempo [Ô]consertando[Ô] as [Ô]incompatibildades[Ô] do que reescrever. Pode-se então concluir que o melhor é SEMPRE reescrever? Calma, não sejamos tão radicais. Como já disse vai depender de como sua aplicação está feita.
Usando esse [Ô]migrador[Ô], tenha em mente alguns aspectos muito importantes:
1 - VB6 usa a tecnologia ADO(a última versão é 2.8). Que é COMPLETAMENTE DIFERENTE do ADO.NET e totalmente obsoleta em comparação. Então quando migrar, você vai ter uma pseudo-aplicação em .NET usando conexão de dados ADO(2.8), ou seja, sua aplicação já vai nascer com uma falha gravÃssima se usar o [Ô]conversor[Ô]
2 - Existem muitas coisas que se fazia no VB6 de uma determinada maneira, mas na plataforma .NET é também completamente diferente e por isso a migração não ocorre de maneira como se espera.
Então, o que o [Ô]migrador[Ô] faz? Basicamente nada realmente útil. Ele vai criar forms, com controles equivalentes aos que você tem na sua aplicação VB6, mas mesmo isso, vai estar meio [Ô]capenga[Ô] porque dependendo do controle, a migração não pode ser feita, especialmente para controles ActiveX não nativos do VB6. Tudo isso nos leva a concluir que:
[txt-color=#e80000]A única coisa que o VB6 e o VB.NET tem em comum é a sintaxe.[/txt-color]
Agora, vamos um nÃvel acima:
Duas coisas diferentes, são saber escrever código e saber programar. [Ô]Como assim?[Ô] você deve estar se perguntando, mas é isso mesmo, escrever código, é muito diferente de programar.
Programar, consiste em saber o que se está fazendo, qual a tarefa que o procedimento está fazendo. Escrever código, é simplesmente saber a sintaxe dos comandos necessários para se fazer uma operação.
Vamos tentar entender com um exemplo prático:
Tarefa: Adicionar uma [Ô]ficha[Ô] com dados de cliente à uma base de dados.
Como fazer?
1 - Saber quais dados que consistem a [Ô]ficha[Ô];
2 - Fazer a conexão com o banco de dados;
3 - Inserir os dados no banco de dados
Isso é a tarefa em nÃvel macro. Vamos supor que os [Ô]dados da ficha[Ô] sejam nome, endereço e telefone. Isso nos leva a concluir que a tabela no banco de dados que conterá nosso cliente, deverá possuir esses campos. Com esse Ãtem conferido, podemos partir para o pseudo-código:
A - Apresentar a tela de preenchimento desses dados de cliente, que conterá um [Ô]botão[Ô] de ação.
B - A ação do botão fará o seguinte:
1 - Conectar com o banco de dados
2 - Criar o comando que insere os dados no banco de dados
3 - Executar o comando que insere os dados no banco de dados
4 - Fechar a janela de preenchimento ao terminar de inserir os dados; Em caso de erro, apresentar o erro ao usuário.
Em pseudo-código:
Show(tela_cadastro_cliente);
Wait(pressionar_botao)
{
Comentário: Aqui é o procedimento de [Ô]clique[Ô] do botão
AbrirConexao(banco_dados);
CriarComandoSQL(Campo_Nome, Campo_Endereco, Campo_Telefone);
ExecutarComandoSQL();
IF (ErroAoInserir)
Show(Mensagem_erro);
ELSE
{
FecharConexao(banco_dados);
Fechar(tela_cadastro_cliente);
}
}
Esse seria o esqueleto da especificação funcional da tela de cadastro de clientes. Ok, sua aplicação faz exatamente isso. Concordo, a funcionalidade é essa, o problema é a maneira que se monta seu programa para que essas ações sejam feitas. Geralmente, os programadores VB6, põem todo esse código no formulário mesmo. Então, o único local que se pode cadastrar um cliente é na sua tela de clientes e nenhum outro local. E isso é que o [Ô]acomplamento[Ô]. A aplicação tem que ser livre para poder fazer qualquer operação em qualquer local. Digamos que você está na tela de venda de produtos, e quer vender para um cliente que ainda não existe. Você vai ter que parar a venda e ir na tela de clientes para gravar ele antes e depois então iniciar novamente a venda.
Não sei se me fiz entender, acho que acabei me excedendo na explicação...
1 - A maioria dos programadores que usam VB6, não seguem e na maioria das vezes nem sabem o que é Orientação a Objeto ou POO. Isso faz com que seus programas tenham um nÃvel de acomplamento muito alto. Acoplamento é a dependência entre objetos, um exemplo disso é [Ô]uma tela que faz tudo[Ô] como um cadastro de clientes por exemplo, todo o código necessário para manipular e consultar clientes está no código do form.
2 - O Ãtem acima, é parcialmente culpado pelo próprio VB6 que não possui uma orientação a objeto sólida, encorajando a usar a programação [Ô]procedural[Ô] que por si só, tem um alto nÃvel de acomplamento.
3 - VB.NET não é só [Ô]um upgrade do VB6[Ô], é todo um conjunto de conceitos e paradigmas que devem ser dominados antes de se começar a trabalhar com ele, como a orientação a objeto por exemplo
Com isso temos algumas ponderações a serem feitas:
1 - Qual o tamanho da minha aplicação?
2 - Qual o nÃvel de acomplamento dela?
3 - Quão necessário é que eu faça uma migração?
Se sua aplicação é bem grande e com alto nÃvel de acomplamento, tenho más notÃcias: Vai dar um trabalhão para migrar tudo, tanto que é melhor mesmo reescrever tudo do zero, usando os conceitos que a plataforma .NET oferece(logicamente, dominando-os antes). O Visual Studio tem um [Ô]migrador[Ô], uma ferramentazinha fuleira para a [Ô]migração[Ô] do seu código VB6 para .NET, mas dependendo do nÃvel de acomplamento e tamanho da sua aplicação, você vai levar 3 vezes mais tempo [Ô]consertando[Ô] as [Ô]incompatibildades[Ô] do que reescrever. Pode-se então concluir que o melhor é SEMPRE reescrever? Calma, não sejamos tão radicais. Como já disse vai depender de como sua aplicação está feita.
Usando esse [Ô]migrador[Ô], tenha em mente alguns aspectos muito importantes:
1 - VB6 usa a tecnologia ADO(a última versão é 2.8). Que é COMPLETAMENTE DIFERENTE do ADO.NET e totalmente obsoleta em comparação. Então quando migrar, você vai ter uma pseudo-aplicação em .NET usando conexão de dados ADO(2.8), ou seja, sua aplicação já vai nascer com uma falha gravÃssima se usar o [Ô]conversor[Ô]
2 - Existem muitas coisas que se fazia no VB6 de uma determinada maneira, mas na plataforma .NET é também completamente diferente e por isso a migração não ocorre de maneira como se espera.
Então, o que o [Ô]migrador[Ô] faz? Basicamente nada realmente útil. Ele vai criar forms, com controles equivalentes aos que você tem na sua aplicação VB6, mas mesmo isso, vai estar meio [Ô]capenga[Ô] porque dependendo do controle, a migração não pode ser feita, especialmente para controles ActiveX não nativos do VB6. Tudo isso nos leva a concluir que:
[txt-color=#e80000]A única coisa que o VB6 e o VB.NET tem em comum é a sintaxe.[/txt-color]
Agora, vamos um nÃvel acima:
Duas coisas diferentes, são saber escrever código e saber programar. [Ô]Como assim?[Ô] você deve estar se perguntando, mas é isso mesmo, escrever código, é muito diferente de programar.
Programar, consiste em saber o que se está fazendo, qual a tarefa que o procedimento está fazendo. Escrever código, é simplesmente saber a sintaxe dos comandos necessários para se fazer uma operação.
Vamos tentar entender com um exemplo prático:
Tarefa: Adicionar uma [Ô]ficha[Ô] com dados de cliente à uma base de dados.
Como fazer?
1 - Saber quais dados que consistem a [Ô]ficha[Ô];
2 - Fazer a conexão com o banco de dados;
3 - Inserir os dados no banco de dados
Isso é a tarefa em nÃvel macro. Vamos supor que os [Ô]dados da ficha[Ô] sejam nome, endereço e telefone. Isso nos leva a concluir que a tabela no banco de dados que conterá nosso cliente, deverá possuir esses campos. Com esse Ãtem conferido, podemos partir para o pseudo-código:
A - Apresentar a tela de preenchimento desses dados de cliente, que conterá um [Ô]botão[Ô] de ação.
B - A ação do botão fará o seguinte:
1 - Conectar com o banco de dados
2 - Criar o comando que insere os dados no banco de dados
3 - Executar o comando que insere os dados no banco de dados
4 - Fechar a janela de preenchimento ao terminar de inserir os dados; Em caso de erro, apresentar o erro ao usuário.
Em pseudo-código:
Show(tela_cadastro_cliente);
Wait(pressionar_botao)
{
Comentário: Aqui é o procedimento de [Ô]clique[Ô] do botão
AbrirConexao(banco_dados);
CriarComandoSQL(Campo_Nome, Campo_Endereco, Campo_Telefone);
ExecutarComandoSQL();
IF (ErroAoInserir)
Show(Mensagem_erro);
ELSE
{
FecharConexao(banco_dados);
Fechar(tela_cadastro_cliente);
}
}
Esse seria o esqueleto da especificação funcional da tela de cadastro de clientes. Ok, sua aplicação faz exatamente isso. Concordo, a funcionalidade é essa, o problema é a maneira que se monta seu programa para que essas ações sejam feitas. Geralmente, os programadores VB6, põem todo esse código no formulário mesmo. Então, o único local que se pode cadastrar um cliente é na sua tela de clientes e nenhum outro local. E isso é que o [Ô]acomplamento[Ô]. A aplicação tem que ser livre para poder fazer qualquer operação em qualquer local. Digamos que você está na tela de venda de produtos, e quer vender para um cliente que ainda não existe. Você vai ter que parar a venda e ir na tela de clientes para gravar ele antes e depois então iniciar novamente a venda.
Não sei se me fiz entender, acho que acabei me excedendo na explicação...
Tópico encerrado , respostas não são mais permitidas