JoséQuintas escreveu:Puxar pelo git ajudaria mas.....
git clone endereco32
dentro da pasta
git pull endereco34
O próprio git mostra aonde não consegue juntar automático, devido a conflitos, mas e pra saber se estamos indo em frente ou voltando pra trás?
Tem que estar muito acostumado com as mudanças pra não fazer besteira.
Não sei nem mesmo se para o Viktor, se isso já não seria complicado.
Talvez até mais interessante alterar direto no 3.2 pra ter aproveitamento ainda maior, e provável ajuda.
O melhor caminho é identificar as alterações importantes/interessantes e procurar reproduzi-las, visto que tem a mudança para C++ em andamento. Harbour 3.2, Harbour 3.4 e xHarbour continuarão em C, mas o Harbour++ usará cada vez os recursos da linguagem C++.
Na série 1 (versões 1.#.#), tenho de restringir o uso do C++ por causa da compatibilidade. Este série serve como porta de entrada para quem decidir passar de Harbour/xHarbour para Harbour++.
Mas na série 2 (versões 2.#.#), poderei intensificar o uso do C++. E deixar a compatibilidade em segundo plano, podendo então mexer no conjunto de comandos, classes e funções. isto inclui, inclusive, aproveitar ideias de outros produtos xBase (Flagship, Recital, VFP, dBase, etc...)
Mas nada drástico, que obrigue o desenvolvedor a ficar reescrevendo seu código-fonte. Seriam novos recursos e ajustes para acompanhar o desenvolvimento do Harbour++.
JoséQuintas escreveu:O que gostei foi muita função de API que ficava em gtwvg/gtwvw/etc. serem movidas pra hbwin, e padronizadas nas libs.
E também um tipo de variável (acho que é isso) especÃfica para o uso de formatos do windows, pra facilitar o uso de funções.
Com isso, a hbwin do 3.4 tem muito mais funções do que no 3.2, inclusive as usadas em GUI.
Talvez até tenha a ver com o que anda fazendo pra facilitar o uso de API Windows.
Na hbwin, o uso de estruturas foi resolvido desta forma:
. os dados são armazenados em variáveis do tipo HASH
. antes de chamar uma função do Windows, é criado uma estrutura e os valores são copiados do hash para a estrutura
. a função da winapi é chamada usando a estrutura recém criada
. se necessário, os valores são copiados da estrutura para o hash
. a estrutura é descartada
Na hbwinapi, optei por criar a estrutura na criação do objeto (usando o new do C++). O endereço da estrutura fica armazenado na propriedade 'pointer'. É este valor que é passado para as funções da API do Windows. Os valores são obtidos e alterados diretamente na estrutura. Enquanto o objeto existir, a estrutura existirá. Com o fim do objeto, a estrutura é destruÃda no 'destructor' da classe (usando o delete do C++).
Conforme a hbwinapi evoluir, os projetos da pasta contrib (exceto hbwin) serão alterados para usarem os recursos dela. Funções duplicadas serão marcadas como obsoletas, mas continuarão disponÃveis para que os desenvolvedores continuem usando, se desejarem.
De certa forma, é semelhante ao processo que ocorreu no Harbour 3.4.
Os recursos que se tornarem obsoletos numa série poderão ser removidos na série seguinte. Por exemplo: funções que se tornarem obsoletas na série 1 poderão ser removidas na série 2. Assim, haverá tempo para acompanhar as mudanças e fazer os devidos ajustes.