Saindo do Delphi 7 de última hora

[bnobre]

Acabo de tomar um "tapa na cara". Eu sabia e me adaptei a mudança do trunk, do novo fortes, da nova pasta Schemas, mas NUNCA reparei na questão do fim do suporte ao Delphi 7. Soube agora através de um e-mail da TecnoSpeed anunciando que o ACBr não daria mais suporte ao Delphi 7. Imaginem como estou "sem chão", pelo que li no tópico muita gente ficou desesperada com 6 meses de antecedência, e eu vou ter que começar agora.

Mas não adianta mais chorar o "leite derramado"... Agora é bola pra frente e dar meu jeito, mas gostaria da opinião de vocês para me colocarem no melhor caminho. Como programador só tenho experiência no Delphi 7, é a única linguagem que conheço e trabalho há 10 anos e por isso quero a sugestão de vocês. Ou eu migro para um novo Delphi ou migro para o Lazarus.

Os 2 componentes de terceiros que mais uso é o Jedi VCL e o ZeosLib...

O Zeos já verifiquei que tem suporte até o X7 e Lazarus, o que torna necessário que use o Delphi XE7 caso opte pelo Delphi.

O problema é que o Jedi apesar de ter suporte até o XE10, não suporta o Lazarus a principio, pois andei olhando "por alto" que alguns conseguem fazer ele rodar de forma alternativa

Pois bem, dado essas características de experiência com o visual e programação no Delphi 7 e componentes citados, qual seria a melhor escolha para mim?

Estou muito preocupado por isso, pois será um caminho árduo, portanto quero optar o que me dê menos dor de cabeça agora e a longo prazo.

Desde já agradeço a atenção de todos

[Waldir Paim]

@doidopb

Fique calmo, não precisa fazer na correria, como já foi dito nesse poste mesmo, não será quebrado o suporte e sim nesse momento não será mais testado oficialmente pela equipe do ACBr.

Veja aqui na pagina anterior: 

Citar

 

Isso não impede que os interessados mantenham a compatibilidade e façam os testes.

 

[bnobre]

Obrigado pelas palavras Waldir, estou tenso aqui.  

Mas tenho certeza que tirarei algo de bom nisso, assim como todos os outros, que é a mudança para uma plataforma mais atualizada.

Estou precisando de umas dicas para saber qual plataforma trilhar esse caminho, caso esse não seja o tópico mais apropriado peço desculpas desde já. Estou tendendo para o Lazarus, apesar da dificuldade do Jedi, devido o fator financeiro, mas fico receoso de o projeto entrar em desuso por ser Free e depois ficar "a ver navios".

Quanto ao Delphi o problema é o valor. Alguém sabe os benefícios obtidos pela aquisição do mesmo, além claro de poder utilizá-lo? E as diferenças entre as vezes que oscilam de R$ 2.000,00 até R$ 10.000,00?

Desde já agradeço a atenção de todos

[Juliomar Marchetti]

Boa noite!

estranho só ter essa informação agora!

se anunciamos amplamente, por meio de posts, anúncios e outros meios aqui no fórum mesmo desde a metade do ano passado!

o pessoal da tecnospeed quer vender o jabá deles pois o ACBr em sua gigantesca maioria é usado pelos programadores!

sinceramente não é preocupação mas sim uma grande oportunidade em dar um up em sua aplicação com essa situação e mudar de versão de IDE

conforme pode ler acima e se der uma olhada geral o pessoal está conseguindo fazer essa mudança de boa!

aproveite e faça um refactoring em seu código e em toda a sua aplicação!

[bnobre]

1 minuto atrás, Juliomar Marchetti disse:

Boa noite!

estranho só ter essa informação agora!

se anunciamos amplamente, por meio de posts, anúncios e outros meios aqui no fórum mesmo desde a metade do ano passado!

o pessoal da tecnospeed quer vender o jabá deles pois o ACBr em sua gigantesca maioria é usado pelos programadores!

sinceramente não é preocupação mas sim uma grande oportunidade em dar um up em sua aplicação com essa situação e mudar de versão de IDE

conforme pode ler acima e se der uma olhada geral o pessoal está conseguindo fazer essa mudança de boa!

aproveite e faça um refactoring em seu código e em toda a sua aplicação!

Sim Juliomar, infelizmente apesar de frequentar constantemente como pode observar pelos meus posts (inclusive alguns trocados contigo), só vi agora, mas como eu disse não adianta "chorar o leite derramado". Também vejo como uma oportunidade, assim como disse.

Mas como falei, preciso de um princípio para dele deslanchar, construindo algo o mais estruturado possível para não ser pego de surpresa novamente no futuro e ter que mudar tudo...O que acha... Lazarus ou Delphi? Prós e contras de cada um. 

Desde já agradeço a atenção

[Robertson Matos]

Um membro da minha equipe já conseguiu converter de Delphi 6 -> Delphi 7 (1 Semana) -> Delphi 10.1 Berlim (10 dias). 

A ideia para o futuro agora é converter para Delphi XE. Mas aí o buraco é mais embaixo. Mas creio que todo mundo só tem a ganhar com a "obrigação" da maioria de converter para plataformas mais atualizadas.

Boa sorte à todos!

[Marcelo Calvi Belanga]

Estou aqui apenas para compartilhar um pouco da minha experiência....

Sou usuário do ACBR de poucos meses e desde então tenho informações da mudança.

Usava um componente de terceiro que só estava me dando dor de cabeça.

Sou desenvolvedor Delphi 7 de muitos anos e não tive maiores problemas com a migração. 

Não tive que mudar quase nada, incluindo componentes de terceiros. 

E por hora só tive a ganhar, principalmente em desempenho, visual, etc.

Para mim foi a oportunidade de melhorar...

[Daniel Simoes]

Hoje em dia, o risco maior, é continuar a usar o Delphi 7...

Hoje, no Windows 10, ao iniciar o Delphi7, é exibida uma janela "ameaçadora", informando que o programa não é compatível e que deve ser atualizado...

Ou seja, as chances do binário gerado por esse compilador não serem suportadas total ou parcialmente pelo Windows 10, são grandes...

 

[bnobre]

2 minutos atrás, Daniel Simoes disse:

Hoje em dia, o risco maior, é continuar a usar o Delphi 7...

Hoje, no Windows 10, ao iniciar o Delphi7, é exibida uma janela "ameaçadora", informando que o programa não é compatível e que deve ser atualizado...

Ou seja, as chances do binário gerado por esse compilador não serem suportadas total ou parcialmente pelo Windows 10, são grandes...

 

Olá Daniel, bem observado... Acha que tenho mais a ganhar com Lazarus ou Delphi?

[Daniel Simoes]

Delphi XE é um produto superior ao Lazarus... com um ótimo conjunto de frameworks e suporte a mobile...  porém é (muito) caro...

Com Lazarus você terá mais liberdade, e suporte a Linux / Mac.. (o que foi determinante no meu caso)

A migração de um sistema D7 será muito mais simples, se for para um novo Delphi, do que para Lazarus

[Mauro Asl]

Mude para um delphi mais atualizado.

Ex: Xe7 etc...

Fica uma sugestão de migração.

No delphi mais atualizado, instale e configure os componentes do ACBr, depois crie uma(s) dll com suas necessidades e a utilize no seu D7. Isito será bém mais rápido.

Com isto você ganha mais tempo para migrar seus projetos.

Há muitos anos atrás, minha migração foi feita assim do D7 para 2009.

Abraços e espero ter ajudado.

 

[Juliomar Marchetti]

Só uma ressalva! enquanto ele fica criando a dll ele consegue fazer a migração!

[Mauro Asl]

3 horas atrás, Juliomar Marchetti disse:

Só uma ressalva! enquanto ele fica criando a dll ele consegue fazer a migração!

Depende do ponto de vista Juliomar!

 Se o(s) projeto(s) tiverem muitos componentes de terceiros que não existam nas versões mais recentes do Delphi, será um pouco mais demorado a migração.

O pessoal está com receio de uma hora para outra seus projetos não mais compilarem. Não estão entendendo que até chegar a este ponto, vai demorar um pouco.

Na época eu fiz isto "dll', pois tinha muita dependência. Até eu me desvincular, demorei um pouco.

Mas, é uma sugestão ! Cada um vê o que é melhor e nós estamos aqui para colaborar !

Abraços.

[bnobre]

Olá a todos, parece que meu temor foi exagerado. 

Aparentemente meu projeto de NFCe já está compilando normalmente no Delphi 2010, acabei optando pelo 2010 por conta de alguns componentes de terceiros.

A questão é que observei a presença de alguns alertas do tipo " W1058 Implicit string cast with potential data loss from ‘string’ to ‘AnsiString’". Ao usar o "Analyse to Project" do menu Project, observei que tais alertas também estão presentes em várias units do projeto ACBr.

De acordo com o link http://www.andreanolanusse.com/pt/delphi-unicode-entendo-os-avisos-warning-do-compilar-sua-aplicacao/, posso ter problemas caso ocorram a presença de caracteres WideString(padrão default agora no 2010) indo para o AnsiString(padrão default do 7).

Alguém está tendo problemas de perda de dados com isso? Eu creio que não, pois como mencionei o próprio projeto ACBr apresentou diversos alertas.

Desde já agradeço a atenção de todos

[Waldir Paim]

@doidopb

Temos um tópico que trata desses avisos nesse link 

 

Podemos continuar esse assunto lá, da uma olhada nos últimos post como consegui remover 100% dos avisos da minha IDE.

Ainda tem algumas contribuições minha que não foram aplicadas, acredito que no seu tempo os administradores devem aplicar ou solicitar alguns ajustes.

[Daniel Simoes]

Para resolver isso em definitivo... seria necessário quebrar o suporte a D7 e converter todos os fontes para UTF8...

[Waldir Paim]

@Daniel Simoes

Esse passo mais cedo ou mais tarde precisar ser dado.

Será que um novo trunk não ajudaria nessa tarefa?

Isso permitir a manutenção do código atual e permitiria uma evolução no trunk novo sem gerar muitos problemas.

[FabianoCunha]

Migrei o meu sistema do Delphi 7 para Xe7, sem muita complicações. Em delphi 7 era zeoslib + Rxlib. Fiz a conversão para Xe7 para Zeoslib + JVCL. Para migrar do Rxlib para JVCL existe uma utilitário que faz a alteração do nome das classes no seu código fonte. Algumas classes ele não fez a mudança, neste caso utilizei o TextPad (localizar e substituir), pois encontrei na internet a referência entre as classes Rxlib e JVCL. Foi tranquilo.

No delphi Xe7 ele vai reclamar do tipo dos campos Fields gerados pelo Zeoslib, Neste caso utilizei o localizar e substituir novamente e tudo certo.  TstringFields para TwideStringFields.

O que deu um pouco de trabalho, foi uns componentes meus. Tive que refazê-los. Os que utilizadam algoritmo de criptografia parou de funcionar, neste caso eu mudei para a lib DCPCrypt-master. 

Levei uma semana para fazer a migração, trabalhando só 3 horas por dia.

[alessandro pancotte]

Amigo,

Uso o Delphi 2007, meu exe estava dando cerca de 40mega compilando como release e 76mega como debug

Mudei pro Xe7 e o exe foi para 106mega e nao da diferenca do debub pra release

Tenho outra aplicacao menor que no 2007 estava dando 9mega e no xe7 foi para 16mega

Detalhe esta aplicacao tem umas 6 telas somente, pois é um programinha que serve somente para emitir nfe/nfce

O teu exe tambem aumentou?

 

[bnobre]

Em 18/08/2016 at 17:39, FabianoCunha disse:

Migrei o meu sistema do Delphi 7 para Xe7, sem muita complicações. Em delphi 7 era zeoslib + Rxlib. Fiz a conversão para Xe7 para Zeoslib + JVCL. Para migrar do Rxlib para JVCL existe uma utilitário que faz a alteração do nome das classes no seu código fonte. Algumas classes ele não fez a mudança, neste caso utilizei o TextPad (localizar e substituir), pois encontrei na internet a referência entre as classes Rxlib e JVCL. Foi tranquilo.

No delphi Xe7 ele vai reclamar do tipo dos campos Fields gerados pelo Zeoslib, Neste caso utilizei o localizar e substituir novamente e tudo certo.  TstringFields para TwideStringFields.

O que deu um pouco de trabalho, foi uns componentes meus. Tive que refazê-los. Os que utilizadam algoritmo de criptografia parou de funcionar, neste caso eu mudei para a lib DCPCrypt-master. 

Levei uma semana para fazer a migração, trabalhando só 3 horas por dia.

Olá Fabiano, tudo bom?

Rapaz, eu migrei do Delpi 7 para o Delphi 2010 também sem muitas complicações.

Assim como no seu caso, o Delphi 2010 reclamou do tipo dos campos Fields gerados pelo Zeoslib, e assim como você tentei utilizar o localizar e substituir tudo de TStringField para TWideStringField. Mas no meu caso fiquei recebendo o erro1.jpg em anexo. Ao responder YES ele tenta marcar o field novamente como TStringField na unit e ao responder NO ele deixa como está, mas no Object Inspector (erro2.jpg) ele continua como TStringField e ao compilar acabo recebendo o erro3.jpg.

Para resolver tal problema tive que ir em cada ZQuery e apagar todos os fields de cada uma,  e depois inseri novamente (CTRL + F), forçando o componente criar os fields com o tipo correto, no caso TWideStringField. Só que desse jeito é bem mais demorado.

Como você conseguiu só pelo Localizar/Substituir?

Abraços

Editado 21 Agosto, 2016 por doidopb

[FabianoCunha]

Em 18/08/2016 at 18:25, alessandro pancotte disse:

Amigo,

Uso o Delphi 2007, meu exe estava dando cerca de 40mega compilando como release e 76mega como debug

Mudei pro Xe7 e o exe foi para 106mega e nao da diferenca do debub pra release

Tenho outra aplicacao menor que no 2007 estava dando 9mega e no xe7 foi para 16mega

Detalhe esta aplicacao tem umas 6 telas somente, pois é um programinha que serve somente para emitir nfe/nfce

O teu exe tambem aumentou?

 

Alessandro, o meu executável saiu de quase 3 mega para uns 17 mega, também não deu diferença entre release e debug.  Não sei o motivo de ter aumentado o tamanho. Vou testar ainda aqueles programas que tem na internet que dizem fazer a redução do exe.

Em 21/08/2016 at 19:06, doidopb disse:

Olá Fabiano, tudo bom?

Rapaz, eu migrei do Delpi 7 para o Delphi 2010 também sem muitas complicações.

Assim como no seu caso, o Delphi 2010 reclamou do tipo dos campos Fields gerados pelo Zeoslib, e assim como você tentei utilizar o localizar e substituir tudo de TStringField para TWideStringField. Mas no meu caso fiquei recebendo o erro1.jpg em anexo. Ao responder YES ele tenta marcar o field novamente como TStringField na unit e ao responder NO ele deixa como está, mas no Object Inspector (erro2.jpg) ele continua como TStringField e ao compilar acabo recebendo o erro3.jpg.

Para resolver tal problema tive que ir em cada ZQuery e apagar todos os fields de cada uma,  e depois inseri novamente (CTRL + F), forçando o componente criar os fields com o tipo correto, no caso TWideStringField. Só que desse jeito é bem mais demorado.

Como você conseguiu só pelo Localizar/Substituir?

Abraços

Amigo, no meu caso deu certo apenas a operação de localizar e substituir. Não precisei apagar os fields do objeto query e inseri-los novamente. Só porque eu utilizei o programa TextPad para fazer a substituição.  Dentro do programa TextPad, existe uma opção de "localizar em arquivos" Find in Files. Procurei em todos os arquivos *.dfm e *.pas. Localizar a palavra TStringField. Quando listar todos os arquivos, é só pedir para o textPad abrir todos. E em seguida fazer a substituição em todos os documentos abertos. Salvar tudo e abrir o Delphi.

Att,

Fabiano Cunha

[bnobre]

Valeu Fabiano, vou testar aqui.

Vi outra diferença aqui e quero comentar, de repente ajuda mais alguém aí com o Zeoslib na migração. 

Um dos meus projetos tinha algumas tabelas com campos que o Zeos sugeria como READONLY, creio que pelo fato de serem campos dinâmicos como os campos "tipo" e "serial" abaixo:

Citar

SELECT _TBL_LIBERAR_ITENS.*, IF(_TBL_LIBERAR_ITENS.id_equipamentos IS NULL, "PRODUTO", _TBL_EQUIPAMENTOS.tipo) AS tipo,  
IF(_TBL_LIBERAR_ITENS.id_equipamentos IS NULL, _TBL_PRODUTOS.descricao, _TBL_EQUIPAMENTOS.serial) AS serial FROM _TBL_LIBERAR_ITENS 
LEFT OUTER JOIN _TBL_EQUIPAMENTOS ON _TBL_LIBERAR_ITENS.id_equipamentos = _TBL_EQUIPAMENTOS.id_equipamentos 
LEFT OUTER JOIN _TBL_PRODUTOS ON _TBL_LIBERAR_ITENS.id_produtos = _TBL_PRODUTOS.id_produtos ORDER BY id_liberar_itens DESC LIMIT 1

No Delphi 7 com Zeoslib 6.6.2-RC, sempre atribui valores para esses campos e o ZQuery aceitava de boa, mesmo estando marcados como ReadOnly. Agora no Delphi 2010 com o Zeoslib 7.1.4-stable ele dá erro, dizendo que o campo não pode ser modificado. Na verdade esse erro é o certo, dado o campo ReadOnly como True, mas na versão antiga do Delphi/Zeoslib ele aceitava.

Outra diferença que eu vi também foi em uma tabela que eu tenho um campo chamado "to", referente ao estado de Tocantins. Mesmo se tratando de uma palavra reservada na versão antiga do Delphi/Zeoslib ele aceitava, agora dá erro no ZUpdateSQL, tive que mudar para outro nome.

A princípio é isso, observando novas necessidades informo aos amigos.

Editado 26 Agosto, 2016 por doidopb

[Gerson De Simone]

Relatando minha experiência migrando do D7 para o XE7, o meu maior problema foi ter demorado para sair do bde para IB, tenho que refazer toda essa parte, já mudei em alguns para Firedac mas acho que o IB é melhor, nos componentes ACBR não tive problemas em alguns casos é melhor, no Sat-Cfe quase obrigatório, como foi citado antes PCHAR tem que mudar para PANSICHAR, no caso das consultas SQL e STOREDPROCEDURE tem varias diferenças, principalmente no tipo de variável nos parâmetros tanto de entrada como retorno, principalmente datetime, outra diferença esta no tamanho do executável, um aplicativo em D7 de 4Mb no XE7 fica com mais de 45Mb, posso estar fazendo algo errado, mas em todos aconteceu isso.

Bom, eu vou apressar a mudança, melhor estar atualizado, mas vai uma dica, fiz um aplicativo que funciona como o AcbrMonitor, esse em XE7, só passo o tipo(NFe/Sat) e o respectivo Nº, fiz a principio pro Sat ficou bom acrescentei a NFe e vou colocar as ECF também, assim ganho mais tempo para migrar ou refazer tudo.

Se durante o processo, notar algum detalhe relevante, vou anotar e compartilhar.

Agradeço a equipe do Projeto ACBr e aos outros colaboradores, pelo excelente trabalho.