bnobre

Bom dia @Daniel Simoes... Funcionou meu amigo... Ele gera a exceção internamente, tenta novamente e envia. Porém vou continuar seguindo o tópico aqui pra ver se alguém descobre o mistério desse erro em ambiente de homologação.

Olá a todos, Mesmo problema aqui em ambiente de homologação... Windows 10, VCRedist atualizado: Configuração do componente: Erro (são 2 em sequência): Porém a exceção disparada para o usuário é a última: Depois desse erro passa a funcionar... Aí depois de um tempo volta a dar esse erro novamente, sempre voltando a funcionar após a primeira exceção. Que mistério!!!!!!!!!!

Simplesmente PERFEITO. kkkkkkkkkkkkkk Qual é a mágica por trás dessa função meu amigo @Daniel Simoes???

Olá a todos... Conseguiu resolver com a Embarcadero @Gr@c@ ??? Fiquei curioso, pois se trata de uma problemática que afeta a todos nós.

Olá a todos, Estou com uma dúvida aparentemente simples, mas apesar de diversas tentativas e configurações não obtive êxito, por isso tento aqui a ajuda de vocês. Eu gostaria de chamar um formulário secundário que apresentaria uma mensagem para o usuário, assim que o formulário principal do meu sistema aparecesse desenhado na tela. O usuário ao terminar de ler a mensagem fecharia o formulário secundário, retornando assim para o formulário principal... Porém o foco não volta para o formulário principal, ficando a barra de título acinzentada, se fazendo necessário um clique do mouse no mesmo para receber o foco. É muito fácil reproduzir esse cenário, aqui eu estou usando o Delphi 11. Basta criar um novo projeto com dois formulário, o principal e o secundário.. No evento OnActivate do form principal execute um comando para chamar o form secundário através do ShowModal, por exemplo: frm_secundario.ShowModal; Com isso feito, ao executar o programa feche o formulário secundário que será aberto, observem que o foco não volta para o principal. Alguém já passou por isso e poderia me ajudar? Desde já agradeço a atenção

Boa tarde meu amigo, Obrigado pelo retorno e provavelmente é pelo tamanho necessário... Mas o grande X da questão é qual lógica foi usada baseada no tamanho para chegar nesse valor? Eu apliquei esse mesmo código com os mesmos valores no meu relatório e ficou perfeito, porém o detalhe é que a largura do meu campo de descrição é diferente, mas deu certo... E eu não sei exatamente porque, já que não conheço a lógica do código em si. O interessante é que essas linhas aparentemente banais simplesmente fazem toda a diferença para o DANFE do ACBr em Fortes não ficar totalmente bagunçado nos itens kkkkkkkkkkkkkkk... Se não houver como responder essa questão pelo Pro, então tentemos no fórum aberto.

É isso aí pessoal, sem o código de tratamento que eu citei dá o mesmo problema que acontece em meu relatório: Portanto parece se tratar de um bug do Fortes Report, tanto que o autor teve que usar tais linha de código como "resolução", já que o componente simplesmente não respeita o posicionamento definido em modo Design. Mas ainda assim resta uma dúvida: Porque o autor escolheu o valor 24 no cálculo da Width do memo de descrição?

Olá meu amigo, Obrigado pelo retorno. Que pena, se a pessoa responsável pelo código pudesse esclarecer seria mais efetivo. Vou realizar o teste sugerido, para ver o que acontece SEM essas linhas de código.

Oi pessoal... Eu pensei aqui, se esse problema acontece comigo, deve ter acontecido também no DANFE do componente NFe em Fortes Report, pois o desenho de um orçamento é similar ao de uma nota fiscal, basicamente um cabeçalho em cima, os itens no meio e um rodapé ao final. Fui dar uma olhada aqui no código para ver se existe alguma tratativa especial em relação ao componente que desenha a descrição do produto, que é onde estou tendo problemas aqui no meu caso. Na unit ACBrNFeDANFeRLRetrato, o referido componente é o rlmDescricao. Observei que no evento BeforePrint do componente do relatório é executado a procedure InicializarDados. Dentro da procedure InicializarDados, dentre outros comandos, temos o seguinte: Bem, aqui claramente o autor se preocupou com a definição da posição e a largura do componente em tempo de execução. Apliquei a mesma ideia aqui no meu código, em tempo de execução posicionei o meu componente descricao a esquerda baseado na linha vertical a esquerda. Também regulei a largura do mesmo em tempo de execução baseado nas linhas verticais a esquerda e direita. Ao fazer isso parei de ter o problema aqui nos meus testes iniciais: Agora gostaria de perguntar ao AUTOR da unit ACBrNFeDANFeRLRetrato: 1 - Porque você fez essa tratativa? Você teve o mesmo problema que eu? 2 - Porque escolheu o valor 24 para regular a descrição? Desde já agradeço a atenção

Olá Para ser sincero não vejo como essa dica poderia me ajudar, pois até onde eu sei a ancoragem funciona nos componentes desenhados em tela(janela) em relação ao container pai. Esse componente é usado em um relatório. Na hora da impressão também são aplicadas a ancoragem de componentes desenhados em tela(janela)? De qualquer forma, tentei aplicar a ancoragem do lado direito no RLMemo que está gerando o problema, conforme a sua sugestão, porém sem sucesso. Na hora de visualizar, tudo certo: Mas na hora de imprimir ou salvar de PDF, ele avança:

Então a princípio RJ, SP e SC confirmados!!!

Olá... o amigo @Robson_Renan informou que em SP não está funcionando ainda:

Bom dia pessoal... Começou a funcionar em Produção aqui no RJ. Finalmente!!!!!!!!

Bom dia... Mesma coisa aqui no RJ, que usa o SVRS. Não está funcionando ainda, só mesmo em homologação.

Como eu poderia fixar então?