DO VB6 PARA VB2008 - PRECISO ME LIBERTAR!
Bom dia!
Mas uma vez to tentando fazer que a migração seja o mais amigável possÃvel, mas sempre tem uns pontos que fico pensativo...
Por exemplo. Hoje não tenho quase problemas para desenvolver um programa em VB6. Penso no programa, como será o banco de dados, relacionamento entre tabelas e pronto. Não tenho dificuldades. Talvez uma duvidazinha aqui, outra ali, mas nada que não resolva. Seja com ajuda do VBM ou pesquisando... No final td fica como o planejado.
O que me incomoda na migração não é ter que [Ô]reaprender[Ô] o VB e o ADO, que aliás achei mto doido... meio assustador à primeira vista. O que eu me incomodo é a quantidade de informação disponÃvel. As fontes de informação (sites, artigos, etc) são sobre o mesmo assunto ([Ô]migrando para o VB.NET.... [Ô] ou [Ô]entendendo ADO.NET[Ô], etc, etc), mas parece que todas elas são desencontradas... Talvez a palavra não seja [Ô]desencontradas[Ô], mas não consigo relacionar, comparar, complementar uma fonte de pesquisa com outra. Não consigo abstrair o núcleo, a essência, que seria justamente entender o novo modo de programar.
Um exemplo muito positivo de uma explicação, foi artigo que encontrei. Ele mostrava de maneira extremamente direta a difereça básica do ADO para o ADO.NET. Olha que legal:
Assim é como eu utilizo no VB6
Assim foi a maneira que o autor encontrou para [Ô]traduzir[Ô] para o VB2008
Esse é o caminho das pedras. Eu uso MySQL, mas não foi difÃcil adaptar.
Claro que ADO.NET é muito mais do que isso.
Uma coisa que complica um pouquinho mais é a maneira que cada um programa. Por exemplo.
No antigo ADO para incluir itens no banco, eu fazia assim:
Ou podemos fazer assim:
Dá na mesma. Faz exatamente a mesma coisa. Uns explicam do primeito jeito e outros do segundo.
Assim como existem maneiras de explicar como incluir dados no banco, existem maneiras de explicar Programação Orientada a Objeto, maneiras de explicar as várias propriedades do ADO.NET, dos controles novos do VB.2008, etc.
é aà que vira uma salada geral.
Um dos meus anseios é como eu vou em descobrir as diferenças do VB6 para o VB2008. Eu tô descobrindo aos poucos, mas tá sendo bem doloroso.
Acho que muitos já viram a propriedade ItemData das ComboBox e ListBox no VB6. Eu as utilizo em praticamente todos os meus softwares para indexar os itens com os seus respectivos IDs do banco de dados. Ex:
ComboBox1.ItemData(ComboBox1.NewIndex) = rs!id
Mas essa propriedade fantástica simplesmente não existe no VB.NET. Mas e pra saber se ela não existe ou se mudou de nome? Ou se mudou de cara ou sei lá o q? Foi um parto, mas encontrei no site do Maroratti que ela realmente não existe. Temos que utilizar técnicas de POO para contornar o que parecia ser um problema... Segui a orientação e funcionou direitinho, já consigo fazer a mesma coisa q fazia no VB2008.
é aà que eu me engasgo. Como muita coisa mudou do VB6 para VB2008, eu nao sei se eu não estou procurando direito, ou se o nome da propriedade mudou, ou se não existe mais... Eu sei, eu sei. é [Ô]só[Ô] pesquisar, estudar... Mas deve ter uma maneira mais simples de identificar pra eu não perder mto tempo. Teria como??????
Um exemplo de propriedade que só mudou, mas ainda existe é na grid.
No VB6, eu usava o FlexGrid. Para manipular um texto fazia assim:
Já no VB2008, apanhei. E com ajuda de vcs, vi que é assim:
Fácil né? Mas na época não foi nada divertido... :)
Essa é a parte menos difÃcil de entender... Mas ainda tem a POO.
Como saber quando utilizá-la?? Quando sento da frendo do VB2008 só me vêm programação estruturada. Eu já li bastante sobre POO, já entendi mta coisa, mas não to conseguindo associar VB6 x POO x VB2008.
Aquela explicação (diferença) de ADO para ADO.NET foi bem legal. Seria muito bom algo parecido com um programa simples mas completo em VB6 e outro EXATAMENTE igual só que em VB2008 e utilizado POO.
Acho q o Xis da questão é esse, pelo menos para mim neste momento....
Sei que não sou o único, mas talvez esse post sirva pra mais alguém conseguir entender abstrair o necessário para se sentir seguro e não perdido com o VB2008.
Não sou preguiçoso. Aprendi VB6 sozinho, assim como muitos aqui. Se eu conseguir abstrarir a base (VB2008, controles, ADO.NET, novas propriedades, POO, etc), o resto eu me viro [Ô]sozinho[Ô]... To me sentindo quando vc vai em uma empresa levantar os requisitos pra desenvover um sistema, mas ninguém consegue passar exatamente como funcionam os processos internos. Todo mundo sabe, mas não conseguem te passar de uma maneira q vc entenda. Aà vc ai pro escritório, começa a escrever o sistema com uma sensação que não é daquele jeito. Aà já viu... Dá até desânimo.
é isso... Alguma sugestão? :)
[]'s
Mas uma vez to tentando fazer que a migração seja o mais amigável possÃvel, mas sempre tem uns pontos que fico pensativo...
Por exemplo. Hoje não tenho quase problemas para desenvolver um programa em VB6. Penso no programa, como será o banco de dados, relacionamento entre tabelas e pronto. Não tenho dificuldades. Talvez uma duvidazinha aqui, outra ali, mas nada que não resolva. Seja com ajuda do VBM ou pesquisando... No final td fica como o planejado.
O que me incomoda na migração não é ter que [Ô]reaprender[Ô] o VB e o ADO, que aliás achei mto doido... meio assustador à primeira vista. O que eu me incomodo é a quantidade de informação disponÃvel. As fontes de informação (sites, artigos, etc) são sobre o mesmo assunto ([Ô]migrando para o VB.NET.... [Ô] ou [Ô]entendendo ADO.NET[Ô], etc, etc), mas parece que todas elas são desencontradas... Talvez a palavra não seja [Ô]desencontradas[Ô], mas não consigo relacionar, comparar, complementar uma fonte de pesquisa com outra. Não consigo abstrair o núcleo, a essência, que seria justamente entender o novo modo de programar.
Um exemplo muito positivo de uma explicação, foi artigo que encontrei. Ele mostrava de maneira extremamente direta a difereça básica do ADO para o ADO.NET. Olha que legal:
Assim é como eu utilizo no VB6
[ô]No VB6
Dim Conexao as ADODB.Connection
Dim rsExemplo as ADODB.Recordset
Set Conexao = New ADODB.Connection
Set rsExemplo = New ADODB.Recordset
Conexao.ConnectionString = [Ô]Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Northwind;Data Source=(local)[Ô]
Conexao.Open
rsExemplo.Open [Ô]SELECT * FROM Customers[Ô], Conexao, adOpenKeyset, adLockReadOnly
Assim foi a maneira que o autor encontrou para [Ô]traduzir[Ô] para o VB2008
[ô]No VB.NET
Imports System.Data.SqlClient
Dim Conexao As New SqlConnection [ô]podemos colocar o New na declaração do objeto, criando a nova instância
Dim Adapter As New SqlDataAdapter
Dim Sel As New SqlCommand
Dim DS As New DataSet
Conexao.ConnectionString = [Ô]workstation id=SERVER; packet size=4096; integrated security=SSPI;[Ô] & _
[Ô] data source=(local);persist security info=False;initial catalog=Northwind[Ô]
Conexao.Open()
Sel.Connection = Conexao
Sel.CommandType = CommandType.Text
Sel.CommandText = [Ô]SELECT * FROM Customers[Ô]
Adapter.SelectCommand = Sel [ô]o DataAdapter é um container para os objetos command, aqui usarei apenas o Select
Adapter.Fill(DS, [Ô]Customers[Ô])
Conexao.Close()
Esse é o caminho das pedras. Eu uso MySQL, mas não foi difÃcil adaptar.
Claro que ADO.NET é muito mais do que isso.
Uma coisa que complica um pouquinho mais é a maneira que cada um programa. Por exemplo.
No antigo ADO para incluir itens no banco, eu fazia assim:
a = [Ô]SC[Ô] & Format(cont, [Ô]0000[Ô])
b = Now
c = Left(txtPL.Text, x - 1)
strSQL = [Ô]INSERT INTO tblsc [Ô] & _
[Ô](codigo,datasc,pl) [Ô] & _
[Ô]VALUES ([ô][Ô] & a & [Ô][ô],[ô][Ô] & b & [Ô][ô],[ô][Ô] & c & [Ô][ô])[Ô]
cn.Execute (strSQL)
Ou podemos fazer assim:
strSQL = [Ô]SELECT * FROM tblsc[Ô]
Set rs = New ADODB.Recordset
rs.Open strSQL, cn, adOpenKeyset, adLockPessimistic
rs.AddNew
rs!codigo = [Ô]SC[Ô] & Format(cont, [Ô]0000[Ô])
rs!datasc = Now
rs!pl = Left(txtPL.Text, x - 1)
rs.Update
rs.Close
Set rs = Nothing
Dá na mesma. Faz exatamente a mesma coisa. Uns explicam do primeito jeito e outros do segundo.
Assim como existem maneiras de explicar como incluir dados no banco, existem maneiras de explicar Programação Orientada a Objeto, maneiras de explicar as várias propriedades do ADO.NET, dos controles novos do VB.2008, etc.
é aà que vira uma salada geral.
Um dos meus anseios é como eu vou em descobrir as diferenças do VB6 para o VB2008. Eu tô descobrindo aos poucos, mas tá sendo bem doloroso.
Acho que muitos já viram a propriedade ItemData das ComboBox e ListBox no VB6. Eu as utilizo em praticamente todos os meus softwares para indexar os itens com os seus respectivos IDs do banco de dados. Ex:
ComboBox1.ItemData(ComboBox1.NewIndex) = rs!id
Mas essa propriedade fantástica simplesmente não existe no VB.NET. Mas e pra saber se ela não existe ou se mudou de nome? Ou se mudou de cara ou sei lá o q? Foi um parto, mas encontrei no site do Maroratti que ela realmente não existe. Temos que utilizar técnicas de POO para contornar o que parecia ser um problema... Segui a orientação e funcionou direitinho, já consigo fazer a mesma coisa q fazia no VB2008.
é aà que eu me engasgo. Como muita coisa mudou do VB6 para VB2008, eu nao sei se eu não estou procurando direito, ou se o nome da propriedade mudou, ou se não existe mais... Eu sei, eu sei. é [Ô]só[Ô] pesquisar, estudar... Mas deve ter uma maneira mais simples de identificar pra eu não perder mto tempo. Teria como??????
Um exemplo de propriedade que só mudou, mas ainda existe é na grid.
No VB6, eu usava o FlexGrid. Para manipular um texto fazia assim:
FlexGrid1.TextMatrix(linha,coluna) = [Ô]teste[Ô]
Já no VB2008, apanhei. E com ajuda de vcs, vi que é assim:
grid.Rows(linha).Cells(coluna).Value = [Ô]teste[Ô]
Fácil né? Mas na época não foi nada divertido... :)
Essa é a parte menos difÃcil de entender... Mas ainda tem a POO.
Como saber quando utilizá-la?? Quando sento da frendo do VB2008 só me vêm programação estruturada. Eu já li bastante sobre POO, já entendi mta coisa, mas não to conseguindo associar VB6 x POO x VB2008.
Aquela explicação (diferença) de ADO para ADO.NET foi bem legal. Seria muito bom algo parecido com um programa simples mas completo em VB6 e outro EXATAMENTE igual só que em VB2008 e utilizado POO.
Acho q o Xis da questão é esse, pelo menos para mim neste momento....
Sei que não sou o único, mas talvez esse post sirva pra mais alguém conseguir entender abstrair o necessário para se sentir seguro e não perdido com o VB2008.
Não sou preguiçoso. Aprendi VB6 sozinho, assim como muitos aqui. Se eu conseguir abstrarir a base (VB2008, controles, ADO.NET, novas propriedades, POO, etc), o resto eu me viro [Ô]sozinho[Ô]... To me sentindo quando vc vai em uma empresa levantar os requisitos pra desenvover um sistema, mas ninguém consegue passar exatamente como funcionam os processos internos. Todo mundo sabe, mas não conseguem te passar de uma maneira q vc entenda. Aà vc ai pro escritório, começa a escrever o sistema com uma sensação que não é daquele jeito. Aà já viu... Dá até desânimo.
é isso... Alguma sugestão? :)
[]'s
As informações não são desencontradas, o problema é que você não está [Ô]começando pelo começo[Ô]. Não adianta tentar encontrar um recurso similar no Vb.Net, porque no fundo isso seria somente uma migração e não aprendizado de um novo paradigma. Pra desenvolver utilizando OOP você precisa abstrair a ferramenta (e linguagem). Se continuar assim só vai se decepcionar mesmo.
Isso não tem nada ver com OOP, você só está tentando migrar sua aplicação dessa forma. Percebe? Aprender onde fica cada recurso num Framework tão vasto só é possÃvel com a prática do dia-a-dia. Com o tempo você se acostuma e fica tudo muito natural, mas a metodologia é preciso repensar mesmo, porque continua influenciado pelo VB6, e isso só vai te atrapalhar.
Citação:FBUR escreveu:
No VB6, eu usava o FlexGrid. Para manipular um texto fazia assim:
FlexGrid1.TextMatrix(linha,coluna) = [Ô]teste[Ô]
Já no VB2008, apanhei. E com ajuda de vcs, vi que é assim:
grid.Rows(linha).Cells(coluna).Value = [Ô]teste[Ô]
Isso não tem nada ver com OOP, você só está tentando migrar sua aplicação dessa forma. Percebe? Aprender onde fica cada recurso num Framework tão vasto só é possÃvel com a prática do dia-a-dia. Com o tempo você se acostuma e fica tudo muito natural, mas a metodologia é preciso repensar mesmo, porque continua influenciado pelo VB6, e isso só vai te atrapalhar.
Realmente o Mordor tem razão principalmente no que tange a entender conceito e não entender operadores !
No fundo não adianta descobrir que você sai de CONST MEUVALOR = [Ô]OI[Ô] para Private MEUVALOR as String = [Ô]OI[Ô], é realmente preciso sim entender a essência.
Assim como você eu também fiquei beeeem assustado quando vi certas mudanças (no ADO principalmente), mas vale lembrar que se houve uma mudança, algo a motivou e isso é que torna a coisa interessante. Ver porque mudou !
Foi tecnologia ?
Foi mudança de cultura ?
Foi em busca de desempenho ?
O legal é se questionar, e entender como o processo funciona para jogar com ele, e não contra ele !
Não desanime, com o tempo os conceitos vão ficando cada vez mais claros.
No fundo não adianta descobrir que você sai de CONST MEUVALOR = [Ô]OI[Ô] para Private MEUVALOR as String = [Ô]OI[Ô], é realmente preciso sim entender a essência.
Assim como você eu também fiquei beeeem assustado quando vi certas mudanças (no ADO principalmente), mas vale lembrar que se houve uma mudança, algo a motivou e isso é que torna a coisa interessante. Ver porque mudou !
Foi tecnologia ?
Foi mudança de cultura ?
Foi em busca de desempenho ?
O legal é se questionar, e entender como o processo funciona para jogar com ele, e não contra ele !
Não desanime, com o tempo os conceitos vão ficando cada vez mais claros.
Obrigado MORDOR!
Sei que isso não ó POO. Talvez meu texto tenha ficado meio bagunçado. é que é tanta coisa pra falar em [Ô]poucas linhas[Ô].
Eu tentei separar: POO, ADO.NET, componentes do VB2008, a linguagem.
Em um momento tentei expressar que é difÃcil saber se eu nao estou encontrando uma propriedade especÃfica, se ela não existe ou se mudou de nome. Isso vc me responde que é no dia a dia, não tem jeito...
Em outro momento, tentei expressar que as explicações de ADO para ADO.NET são feitas de várias formas diferentes, mas mostrando o mesmo resultado final (pelo menos tentando). Isso pra quem está migrando é confuso mesmo.
Em outro momento tentei expressar algo sobre POO. Se sem POO já está complicado, imagina se eu pegar um bom exemplo de VB2008, mas que tenha POO?
Eu to pensendo em fazer um curso para certificação (tipo da IMPACTA, acho q vc conhece www.impacta.com.br) Sei que assim vai ser algo bem do inÃcio. Vc tem toda a razão qdo diz que não estou começando do começo. O problema está sendo enxergar onde é o começo, entende?!
[]'s
Sei que isso não ó POO. Talvez meu texto tenha ficado meio bagunçado. é que é tanta coisa pra falar em [Ô]poucas linhas[Ô].
Eu tentei separar: POO, ADO.NET, componentes do VB2008, a linguagem.
Em um momento tentei expressar que é difÃcil saber se eu nao estou encontrando uma propriedade especÃfica, se ela não existe ou se mudou de nome. Isso vc me responde que é no dia a dia, não tem jeito...
Em outro momento, tentei expressar que as explicações de ADO para ADO.NET são feitas de várias formas diferentes, mas mostrando o mesmo resultado final (pelo menos tentando). Isso pra quem está migrando é confuso mesmo.
Em outro momento tentei expressar algo sobre POO. Se sem POO já está complicado, imagina se eu pegar um bom exemplo de VB2008, mas que tenha POO?
Eu to pensendo em fazer um curso para certificação (tipo da IMPACTA, acho q vc conhece www.impacta.com.br) Sei que assim vai ser algo bem do inÃcio. Vc tem toda a razão qdo diz que não estou começando do começo. O problema está sendo enxergar onde é o começo, entende?!
[]'s
Caro WEBMASTER,
Isso é mto relevante.
Meu objetivo é estar preparado para o futuro... O Windows 7 vem aÃ...
Mas também para me reciclar. Até quando vou saber [Ô]só[Ô] VB6? Não pode... Não é por mudança de emprego. Hj trabalho em uma empresa e uso só VB6 e não temos planos para este ano de começar a desenvolver em VB.NET, (este ano não, mas quem sabe no próximo...). Também trabalho desenvolvimento independente.
Eu quero desfrutar das facilidades que tanto leio sobre o ADO.NET.
Não tenho dúvidas que o VB2008 é uma ferramenta fantástica e melhor que o VB6. Pra que deixar para depois ou só quando a necessidade falar mais alto?
Fora que boa parte do que eu tentei expressar é de mim mesmo. Eu sou assim. Odeio, odeio, odeio não entender as coisa por completo. Sinto que logo será uma necessidade. Não quero ser pego de surpresa.
Vi em vários posts que colegas foram [Ô]obrigados[Ô] a apreder .NET, seja por qq razão. E eu quero estar preparado se isso acontecer comigo.
Resumo:
1- Não é por necessidade imediata, é estar preparado.
2- Não entendi, fico querendo aprender.
3- Gosto mto de comparações. Quando eu começar a me habituar com VB2008, vou fazer um programainha completo em VB6 + MySQL (cadastros, consultas, grids, etc) e vou fazer um igualzinho em VB2008. Idêntico (na medida do possÃvel). Primeiro que isso me ajuda entender mais, segundo que eu vou tentar passar o que eu aprendi adiante. Gosto disso...
Porém, se é para aprender, que seja bem aprendido.
Eu tenho o hábito de fazer manuais de instrução dos meus softwares, comento tin-tin por tin-tin meus códigos fonte. Não importa o quanto eu escreva. Sou mto detalhista. Se garimparmos mto na net encontramos bons exemplos, que dá para entender bem os conceitos, como esse de ADO para ADO.NET que postei. Adorei esse. Na verdade tinha lido vários e vários, mas não entrava na minha caxola. Depois desse que começei a querer gostar do ADO.NET. E tá dando certo... :)
Já faço algumas coisas. Não estou totalmente cru. Mas sabe como é... uma coisa chama outra.... e por aà vai...
[]'s
Isso é mto relevante.
Meu objetivo é estar preparado para o futuro... O Windows 7 vem aÃ...
Mas também para me reciclar. Até quando vou saber [Ô]só[Ô] VB6? Não pode... Não é por mudança de emprego. Hj trabalho em uma empresa e uso só VB6 e não temos planos para este ano de começar a desenvolver em VB.NET, (este ano não, mas quem sabe no próximo...). Também trabalho desenvolvimento independente.
Eu quero desfrutar das facilidades que tanto leio sobre o ADO.NET.
Não tenho dúvidas que o VB2008 é uma ferramenta fantástica e melhor que o VB6. Pra que deixar para depois ou só quando a necessidade falar mais alto?
Fora que boa parte do que eu tentei expressar é de mim mesmo. Eu sou assim. Odeio, odeio, odeio não entender as coisa por completo. Sinto que logo será uma necessidade. Não quero ser pego de surpresa.
Vi em vários posts que colegas foram [Ô]obrigados[Ô] a apreder .NET, seja por qq razão. E eu quero estar preparado se isso acontecer comigo.
Resumo:
1- Não é por necessidade imediata, é estar preparado.
2- Não entendi, fico querendo aprender.
3- Gosto mto de comparações. Quando eu começar a me habituar com VB2008, vou fazer um programainha completo em VB6 + MySQL (cadastros, consultas, grids, etc) e vou fazer um igualzinho em VB2008. Idêntico (na medida do possÃvel). Primeiro que isso me ajuda entender mais, segundo que eu vou tentar passar o que eu aprendi adiante. Gosto disso...
Porém, se é para aprender, que seja bem aprendido.
Eu tenho o hábito de fazer manuais de instrução dos meus softwares, comento tin-tin por tin-tin meus códigos fonte. Não importa o quanto eu escreva. Sou mto detalhista. Se garimparmos mto na net encontramos bons exemplos, que dá para entender bem os conceitos, como esse de ADO para ADO.NET que postei. Adorei esse. Na verdade tinha lido vários e vários, mas não entrava na minha caxola. Depois desse que começei a querer gostar do ADO.NET. E tá dando certo... :)
Já faço algumas coisas. Não estou totalmente cru. Mas sabe como é... uma coisa chama outra.... e por aà vai...
[]'s
Realmente esse é o espirito !
Pode ter certeza que voce eh quem vai sair lucrando, infelizmente a grande massa (no momento) que migra suas aplicacoes, esta migrando por mudanca de tecnologia, compatibilidade ou cronograma.
Ao contrario de quem pegou carona logo no comeco, e foi migrando [Ô]por gosto[Ô] ou [Ô]por curiosidade[Ô]. Faca a coisas sem muita pressa e foque principalmente no entendimento. Se voce se da bem fazendo comparacoes, otimo, mas lembre-se sempre que tudo foi feito com conceitos as vezes ligeiramente diferentes, e em outros casos, totalmente diferentes, logo as comparacoes podem gerar mais perguntas do que respostas.
Pode ter certeza que voce eh quem vai sair lucrando, infelizmente a grande massa (no momento) que migra suas aplicacoes, esta migrando por mudanca de tecnologia, compatibilidade ou cronograma.
Ao contrario de quem pegou carona logo no comeco, e foi migrando [Ô]por gosto[Ô] ou [Ô]por curiosidade[Ô]. Faca a coisas sem muita pressa e foque principalmente no entendimento. Se voce se da bem fazendo comparacoes, otimo, mas lembre-se sempre que tudo foi feito com conceitos as vezes ligeiramente diferentes, e em outros casos, totalmente diferentes, logo as comparacoes podem gerar mais perguntas do que respostas.
Tópico encerrado , respostas não são mais permitidas