Padl / Padr

[Antonio Gomes]

As funcoes abaixo, nao estariam com  a assinatura errada ?

 

PADL = Adiciona string no inicio, left  -esquerda

PADR = adiciona string no final, right - direita

 

 

{-----------------------------------------------------------------------------

  Completa <AString> com <Caracter> a direita, até o tamanho <nLen>, Alinhando

  a <AString> a Esquerda. Se <AString> for maior que <nLen>, ela será truncada

 ---------------------------------------------------------------------------- }

function padL(const AString : AnsiString; const nLen : Integer;

   const Caracter : AnsiChar) : AnsiString ;

var

  Tam: Integer;

begin

  Tam := Length(AString);

  if Tam < nLen then

    Result := AString + StringOfChar(Caracter, (nLen - Tam))

  else

    Result := copy(AString,1,nLen) ;

end ;

 

{-----------------------------------------------------------------------------

  Completa <AString> com <Caracter> a esquerda, até o tamanho <nLen>, Alinhando

  a <AString> a Direita. Se <AString> for maior que <nLen>, ela será truncada

 ---------------------------------------------------------------------------- }

function padR(const AString : AnsiString; const nLen : Integer;

   const Caracter : AnsiChar) : AnsiString ;

var

  Tam: Integer;

begin

  Tam := Length(AString);

  if Tam < nLen then

    Result := StringOfChar(Caracter, (nLen - Tam)) + AString

  else

    Result := copy(AString,1,nLen) ;

end ;

 

[EMBarbosa]

Programador da depressão: "O compilador sempre ignora meus comentários... :("

 

Alguma sugestão acg?

[Antonio Gomes]

Sim, inverter o cabeçalho das funcoes:

PADL = 'TEXTO' + STRINGOFCHAR

 

PADR = STRINGOFCHAR + 'TEXTO';

 

note que ao meu entender, o comentario em cima da funcao está correto, está invertido apenas as letras R e L na implementacao

[EMBarbosa]

Ah, agora que eu entendi...

 

   O problema é que, ao inverter essas duas letrinhas, teríamos que fazer uma busca por todo o código dos componentes para alterar também. Visto que o funcionamento atual é o esperado, devem estar usando a função incorreta.

   Infelizmente eu não vou ter tempo pra fazer isso por agora... Se alguém se habilitar.

 

   Para quem não entendeu, veja uma implementação ou outra implementação com exemplo.

[Daniel Simoes]

Sim... mas se mudarmos isso agora quebraria muito código...

[Juliomar Marchetti]

Com certeza

Estive lendo o tópico e me recordando de alguns lugares que uso no meu sistema as funções e terei que mudar ou somente quando perceber o problema!

[Antonio Gomes]

Estive pensando em mudar para a implementacao em portugues:

 Suponho que PadD = adciona caracteres a direita

 e PadE = adiiciona caracteres a esqueda, funcoes essas na unit ACBrDFeUtil, porém, ao ler a funcao, acredito que ela esteja invertida também: veja:

 

// Penso em um suposto caracter a direita da string... ex: string entrada: 2: len=6  saída =>:  200000

class function DFeUtil.PadD(const AString: string; const nLen: Integer;

  const Caracter: Char): String;

begin

  Result := copy(AString,1,nLen);

  Result := StringOfChar(Caracter, (nLen - Length(Result))) + Result;

end;

 

// Penso em um suposto caracter a esquerda da string... ex: string entrada: 1: len = 6  saída =>:  000001

class function DFeUtil.PadE(const AString: string; const nLen: Integer;

  const Caracter: Char): String;

begin

  Result := copy(AString, 1, nLen);

  Result := Result + StringOfChar(Caracter, (nLen - Length(Result)));

end;

 

Como eu poderia ajudar arrumar isso? Se é que pode ser arrumado.

[Daniel Simoes]

Eu não vejo motivos para mudar isso... Seria um refactoring bastante traumático..

[Antonio Gomes]

ok.

Lembrando apenas para os usuarios que tiverem a mesma funcao em seus sistemas, vulgo, clippeiros, que criaram essa função, que se começar dar problema em string..  apos incluir as units do acbr na uses, deve-se colocar o nome da sua unit propria no codigo fonte, ou isolar as chamadas ao acbr dentro de uma unit que nao seja global.

 

Passei por esse problema aqui, em remessa bancária, não é o pacote acbr boleto usado, mas outro, que por sua vez usa as funcoes.

Assunto encerrado.

[EMBarbosa]

  O modo de arrumar seria renomear as funções de acordo com o que elas fazem e depois buscar em todo o código de todos os componentes, exemplos e projetos do ACBr o uso destas funções para alterar para a chamada correta.

 

  É por isso que é um refactoring traumático. Daria muito trabalho e pode ser suscetível de erros se não o fizer com cautela.

 

  De qualquer forma vou deixar aqui a ideia para se caso alguém algum dia quiser fazê-lo.

 

1) Renomeie a função padL para um nome que não exista, exemplo: xxpadR;

2) Compile todos os componentes, projetos e exemplos;

3) A cada erro que encontrar dizendo que a função padL não foi encontrada, mude para xxpadR;

4) Renomeie a função padR para um nome que não exista, exemplo: xxpadL;

5) Compile todos os componentes, projetos e exemplos;

6) A cada erro que encontrar dizendo que a função padR não foi encontrada, mude para xxpadL;

Agora você tem o código chamando as funções corretamente e falta apenas voltar para o nome correto;

7) Renomeie a função xxpadR para padR e compile todos os componentes, exemplos e projetos para acertar novamente as chamadas;

8) Renomeie a função xxpadL para padL e compile todos os componentes, exemplos e projetos para acertar novamente as chamadas;

[Antonio Gomes]

Elton Barbosa:

Seria uma solução plausível!

Como posso ajudar nisso ?

[Juliomar Marchetti]

Elton Barbosa:

Seria uma solução plausível!

Como posso ajudar nisso ?

Respondendo pelo Elton, é fazer o que ele sugeriu no post acima!

Atualize seu svn deixe ele compatível totalmente com o ACBr sem nenhum ícone dos arquivos diferente de verde

e comece a alteração, lembrando tem que testar todos os componentes que fazem uso!

[EMBarbosa]

Respondendo pelo Elton, é fazer o que ele sugeriu no post acima!

Atualize seu svn deixe ele compatível totalmente com o ACBr sem nenhum ícone dos arquivos diferente de verde

e comece a alteração, lembrando tem que testar todos os componentes que fazem uso!

Não pode esquecer de todos Exemplos e projetos. Como não se sabe exatamente quais fazem uso, seriam todos mesmo.

[Antonio Gomes]

Juliomar, e depois de alterado, mando todo pacote para voces?

Dai vao mudar linha a linha ?

[Juliomar Marchetti]

Juliomar, e depois de alterado, mando todo pacote para voces?

Dai vao mudar linha a linha ?

Após alterar anexa os arquivos alterados aqui que será feito um merge!

lembre de não usar formatador de código pois senão inviabiliza esse merge.

[Régys Silveira]

Talvez uma saída menos dolorosa seja fazer o que o Elton disse usando um software como o WindowsGreep, nele eu posso procurar uma string e trocar por outra automaticamente em todos os arquivos de um diretório.

Com ele seria possível seguir o passo-a-passo e fazer a troca, o problema a meu ver é que essa troca, mesmo usando uma ferramenta não é menos dolorosa.

[EMBarbosa]

Talvez uma saída menos dolorosa seja fazer o que o Elton disse usando um software como o WindowsGreep, nele eu posso procurar uma string e trocar por outra automaticamente em todos os arquivos de um diretório.

Com ele seria possível seguir o passo-a-passo e fazer a troca, o problema a meu ver é que essa troca, mesmo usando uma ferramenta não é menos dolorosa.

 

  Pessoalmente, eu tenho receio do uso desse tipo de ferramenta num escopo tão grande. Talvez não seja o nosso caso específico, mas receio a ferramenta se confundir com as strings ou uma possível falta de padronização no código.

  Contudo, as versões mais novas do Delphi tem o Refactoring->Rename Method que funciona muito bem dentro de um projeto. Acho mais confiável do que uma ferramenta de mudança de string.

 

Mas, na minha opinião, o mais importante é a compilação após a mudança em cada projeto. Isso é o que daria segurança das alterações estarem sendo feitas sem problemas.

[Régys Silveira]

Então Elton, é por isso que acho que de qualquer forma vai ser doloroso, o ACBr hoje tem diversas units, fora que alguns usuários podem estar utilizando os métodos, eu sou um deles, uso extensivamente o ACBrUtil e outros.

Não vejo forma simples de fazer essa mudança, nem uma forma totalmente confiável também.

 

Eu uso o refactoring do delphi a um bom tempo, realmente ele funciona bem no escopo de um projeto, não sei no caso do ACBr que tem vários pacotes, posso tentar, quem sabe criando um grande projeto e adicionando os pacotes a ele e tentando fazer o refactoring, mas ainda vai existir o risco de algo ficar de fora no meu ver.

[Daniel Simoes]

Acho que o que poderíamos fazer, é adicionar uma Observação no cabeçalho das funções PadL e PadR, informando que as mesmas tem o funcionamento inverso do esperado das mesmas funções existentes em linguagens do padrão xBase (Clipper, Harbour, xHarbour, etc)...

Mas a descrição do cabeçalho atual parece estar concisa com o que a função faz..

[EMBarbosa]

Acho que o que poderíamos fazer, é adicionar uma Observação no cabeçalho das funções PadL e PadR, informando que as mesmas tem o funcionamento inverso do esperado das mesmas funções existentes em linguagens do padrão xBase (Clipper, Harbour, xHarbour, etc)...

Mas a descrição do cabeçalho atual parece estar concisa com o que a função faz..

Acho que é uma saída possível.

 

Nota: para esclarecer, não só linguagens xBase. Linguagens C, .net, SQL e pascal também.

 

Só continuaria tendo problema quando alguém que já faz uso de uma mesma função no sistema adicionar na cláusula uses a unit ACBrUtil. Talvez faça isso para acessar alguma outra coisa que não tem nada a ver com essas funções. Lógico, isso pode também ser resolvido com a chamada referenciando a unit correta.

[EMBarbosa]

No trunk2 as funções foram corrigidas pelo Daniel. Valeu Daniel.