Data Lider

O Firemonkey pode ser dividido em duas fases, XE2 até XE6 e XE7 até XE8, a criação foi realizada para a segunda geração. Como dito no tópico, nem todos os eventos foram vinculados ao TMainMenu, seria muito interessante se você que dispõe da versão XE5 cria-se outra variante do projeto para a primeira geração do Firemonkey além de vincular os restantes dos eventos, seria de grande ajuda, toda colaboração é bem vinda. Sem contar que é mais simples descer uma versão FMX2 para FMX1 do que fazer VCL toda para FMX. O XE7 foi um divisor de aguas em termos de dispositivo móvel, grandes alterações em classes que não eram alteradas desde o XE2, além da adição da propriedade "FMX.Edit.TEdit.ControlType" que trouxe mais competitividade para aplicativos no ANDROID e IOS criados no Delphi, que antes sofriam com desempenho. Isso é um assunto grande, mas contamos com sua colaboração.

Só confirmando, então basicamente quando definindo o conjunto completo, em vez de esperar a compatibilização por parte a IDE já toma a decisão correta? Versão Correta (Sua Implementação) {$IFNDEF NOGUI} {$IF DEFINED(VisualCLX)} ,QDialogs {$ELSEIF DEFINED(FMX)} ,FMX.Dialogs, System.UITypes {$ELSE} ,Dialogs {$IFEND} {$ENDIF}; Versão Indecisa ,Dialogs {$IFDEF FMX} System.UITypes //Sem adicionar o dialog para o FMX, o código fica sem saber quando é vcl ou fmx {$ENDIF}

Atenção para XE2+ Bom, essa semana estamos com necessidade de utilização de dois projetos em ambos ambientes VCL e FMX, enfrentamos alguns problemas de compilação das Unit ACBR, e principalmente versões geradas incorretas porque a SCOPE estava invertida no momento da compilação, então vou adicionar algumas informações para registro e pesquisa de usuários. Projeto 1 - VCL Projeto 2 - FMX Problema 1 - A ACBr.INC é unificada dentro da pasta de fontes do componente ACBrCupom, sempre quando necessário compilar um projeto de cada framework era necessário a troca. Solução - Excluído o arquivo, e adicionado na pasta dos projetos, cada um com sua definação VCL ou FMX. ------------------------ Problema 2 - Mesmo adicionado essas definições, existe o conflito de Units, eu posso ter "Dialog" para VCL (VCL.Dialog) como também para FMX (FMX.Dialog). Em quanto essa dúvida não for respondida não é possível compilar o projeto, para não ter que alterar todas as units do projeto, é necessário ir em Tools -> Options -> Delphi Options -> Libary e então preencher o campo "Unit scope names:" com o valor padrão, seja ele VCL ou FMX, assim é possível saber de qual dialogo será compilado. Isso gera problemas como compilar units VCL dentro do Firemonkey (sim é isso é possível) e trazer problemas futuros para o projeto, principalmente de você trabalhar como OSX que é o nosso caso, nos enfrentamos fechamento de janelas inexplicáveis por esse motivo. Solução - Deixar o campo em branco, e definir a Unit scope names no projeto, basta ir em "Project > Options > Delphi Compiler > Unit Scope Names" e então clicar em "..." e adicionar. (Lembrando que isso é armazenado por configuração, o use seja você precisa configurar tanto em Debug como Release).

Prezado, quando fiz a compilação do meu PAF, me deparei com os seguintes arquivo sem conversão para firemonkey, no caso os diálogos. ACBrBase (ACBrComum). ACBrECFNaoFiscal (ACBrSerial). ACBrECFSchalter (ACBrSerial). ACBrECFSweda (ACBrSerial). Os arquivos foram alterados e estão compilando normalmente agora. Já utilizando Trunk 2. ACBrComum e ACBrSerial.zip

Não pelo contrário, se for bem testado e funcional podemos deixar. Foi meio trabalhoso porque o aplicativo parece pequeno, mas não é, são muitas abas para desenhar e tudo mais. Porém conforme sugerido, eu tirei a madrugada de hoje para fazer a conversão, pouca coisa foi testada, mas o básico já foi testado. Estou postando o anexo logo, para caso alguém queira prosseguir, eu somente vou poder dar continuidade da aqui 1 ou 2 semanas. O que falta ? (Já está funcionando, e operando, são apenas pendências). Adicionar os eventos já convertidos aos seus respectivos itens do TMainMenu (20 minutos). Testar todas as rotinas. O código do TWebBrowser foi comentado, a pesar de existir o componente para o firemonkey, o código precisa ser atualizado. O que foi testado ? Comunicação Mensagens (PopUp Msg). Relatórios (Leitura X etc..) obs: Quem for testar, lembrar que a ACBr.INC tem que ser modificada para testar no firemonkey. Projeto completo em anexo. Firemonkey.zip

O meu deu a mesma coisa, fiz a instalação manual, e está tudo ok agora. (Windows 10).

Durante os testes achei um problema que a primeira vista parece ser na conexão, porém é na seguinte linha de código: {$IFDEF FMX} Application.MainForm.BringToFront ; {$ELSE} Application.BringToFront ; {$ENDIF} Quando é utilizada formulários que são exibidos antes do principal, como splash, configuração de conexão etc.. a variável MainForm ainda não foi contemplada com o formulário, a correção foi: {$IFDEF FMX} if Assigned(Application.MainForm) then Application.MainForm.BringToFront ; {$ELSE} Application.BringToFront ; {$ENDIF} Arquivo completo com a alteração em anexo. ACBrECFClass.pas

21/08/2015 - 13:12 - Atualização Boa tarde Isaque, conforme sugerido, eu fiz as alterações, porém mantive também o padrão VCL no FMX. Uma observação é que visando mantar poucas alterações para chegar ao resultado, e evitar vazamento de memória, mantive a linha que libera o formulário após a utilização, portanto o formulário que será enviado pelo usuário será estanciado no momento da utilização. Para sua sugestão foram criados dois eventos: OnCriarFormMsg - Utilizado para anexar o formulário que o usuário quiser ao componente no momento da chamada do procedimento FormMsgDoProcedure. OnDrawFormMsg - Utilizado no momento que a mensagem é enviada para ser desenhada, FormMsgPinta. O exemplo de utilização é: TForm1 = class(TForm) ACBrECF1: TACBrECF; Button1: TButton; procedure Button1Click(Sender: TObject); procedure ACBrECF1CriarFormMsg(var CustomForm: TForm); procedure ACBrECF1DrawFormMsg(const Mensagem: string); private { Private declarations } public { Public declarations } Msg: TForm2; //O tipo é do meu formulário personalizado. end; //############################################################# procedure TForm1.ACBrECF1CriarFormMsg(var CustomForm: TForm); begin Msg := TForm2.Create(Self); //Essa variável será liberada após uso CustomForm := Msg; end; procedure TForm1.ACBrECF1DrawFormMsg(const Mensagem: string); begin {Posso enviar para um TText ou TLabel, Canvas ou mesmo chamar um procedimento próprio que trata a mensagem. } Msg.Text1.Text := Mensagem; end; procedure TForm1.Button1Click(Sender: TObject); begin if not ACBrECF1.AcharPorta then ShowMessage('Falha') else ShowMessage(ACBrECF1.Porta); end; Os dois modos foram testados e estão funcionando corretamente, por padrão o funcionamento é utilizando o formulário igual o da VCL, se o usuário quiser ativar o recurso de formulário personalizado basta utilizar os eventos, ficou muito simples. Para ver um formulário personalizado com o logo da ACBr piscando clique no link https://youtu.be/hvHZnLyM9vE Qualquer dúvida estou a disposição, os novos arquivos estão em anexo. ACBrECFClass.pas ACBrECF.pas

Bom Dia, bom, de qualquer maneira fica o exemplo para quem não quiser criar o próprio formulário. Porque na VCL não permite criar o próprio formulário também? Eu penso no seguinte, fica mais simples para o usuário ter um componente que pode ser testado sem intervenção, se ele quiser personalizar a mensagem, então ele utiliza o recurso (que tem que ser implementado ainda), mas seria interessante mantar o código alterado para quem não quer se preocupar com esses detalhes. Até para quem está migrando da VCL e já está acostumado com o tipo de mensagem trabalhada pela ACBr. Você realmente acha um problema mantar os dois modos ?

Bom, depois de muitas horas, consegui colocar para funcionar a função de procurar porta no Firemonkey. Não tive a oportunidade de testar todo o componente, mas pelo que pude verificar a única coisa que impedia ele de funcionar como deveria era o formulário de diálogo do ACBrECF. Então venho aqui trazer as modificações e suas justificativas. Observações Todas as alterações foram testadas em uma impressora DARUMA MACH 2. A versão do Delphi foi XE8 Trial, muito provável alguma coisa ou outra não vá funcionar em XE5-XE2 sem alguma alteração muito pequena.(talvez apenas tipos). Foi adicionado um IFDEF VER290(XE8) , cabe a alguém testar em versões anterior e verificar o funcionamento. Novas USES (Somente FMX) System.Character - Utilizada para conversão em variáveis do tipo CHAR. System.Types - Utilizada para utilização em run-time de variáveis do tipo TRectF em canvas do Firemonkey. System.UIConsts - Utilizada para conversão de variáveis do tipo cor do Firemonkey (TAlphaColor). Problemas Encontrados Não era possível exibir formulários em run-time no firemonkey, apresentava erro de resource, a solução foi utilizar o CreateNew: {$IFNDEF FMX} fsFormMsg := TForm.create( Application ) ; {$ELSE} fsFormMsg := TForm.CreateNew( Application ) ; {$ENDIF} A cor de fundo do formulário não era alterada: fsFormMsg.Fill.Kind := TBrushKind.Solid; As propriedades da fonte como também sua cor não era possível de serem alteradas (foi adicionado uma tarefa por vocês para futuro). Uma observação é que a propriedade "TagStr",é presente em todos os componentes Firemonkey. <b>ACBrECF.pas</b> - Adicionado nova propriedade para cor de fonte apenas para o firemonkey property FormMsgColorFont : TAlphaColor read fsFormMsgColorFont write fsFormMsgColorFont ; //Realiza composição das 3 informações em apenas 1 tag fsFormMsg.TagString := ECF.FormMsgFonte.Size.ToString + ';' + ECF.FormMsgFonte.Family + ';' + AlphaColorToString(ECF.FormMsgColorFont); <b>ACBrECFClass.pas</b> - Depois é desmontada para leitura das informações //Carregando informações da fonte, family e cor with TStringList.Create do try StrictDelimiter := True; Delimiter := ';'; DelimitedText := fsFormMsg.TagString; fsFormMsg.Canvas.Font.Size := Strings[0].ToSingle; fsFormMsg.Canvas.Font.Family := Strings[1]; fsFormMsg.Canvas.Fill.Kind := TBrushKind.None; fsFormMsg.Canvas.Fill.Color := StringToAlphaColor(Strings[2]); finally Free; end; A rotina de desenho não estava adequada para o Firemonkey. fsFormMsg.Width := Round(fsFormMsg.Canvas.TextWidth(Texto)) + 25; fsFormMsg.Height := Round(fsFormMsg.Canvas.TextHeight(Texto))+ 15; Application.ProcessMessages; //Se não adicionar essa linha, o firemonkey não faz a pintura o texto. fsFormMsg.Canvas.BeginScene; //Todo canvas no firemonkey é necessário este bloco de proteção. try fsFormMsg.Canvas.StrokeThickness := 1; //Espessura do pincel. fsFormMsg.Canvas.FillText(TRectF.Create(0, 0, fsFormMsg.Width, fsFormMsg.Height), Texto, True, 100, [], TTextAlign.Center, TTextAlign.Center); finally fsFormMsg.Canvas.EndScene; end; Por ultimo, e não menos importante, a rotina de pressionar a tecla para cancelar o dialogo não estava funcionando, o código informado não atende a situações diversas que o Firemonkey apresenta no OnKeyDown. O Firemonkey quando pressionado por uma tecla que não é dita como especial, a variável KeyChar é preenchida, porem se você utilizar uma tecla como F1 ou ENTER o KeyChar fica em branco, então o Key é preenchido. if (fsFormMsgTeclaParaFechar <> 0) and (fsFormMsgEstado <> fmsAbortado) then begin if (KeyChar <> #0) and (Integer(KeyChar.ToUpper) = fsFormMsgTeclaParaFechar) then fsFormMsgEstado := fmsAbortado else if (Key > 0) and (Key = fsFormMsgTeclaParaFechar) then fsFormMsgEstado := fmsAbortado else begin Key := 0; KeyChar := #0; end; end; ACBrECFClass.pas ACBrECF.pas

Eu estou usando o componente para unificar dois sped de filiais diferentes, tem gente que usa para alimentar tabelas (para softwares de contabilidade é bem útil). No caso de software de contabilidade portar este componente para sped fiscal também seria interessante. Não estou participando muito da conversa, porque estamos produzindo PAF-ECF então estou mais distante.

Alguém que tem controle do SVN poderia por favor subir as alterações atuais, porque está acumulando, e pode ficar difícil depois para diferenciar, no momento temos a alteração de data, de um tipo de um determinado campo e ainda da forma como o arquivo é lido em outras IDEs.

Você pode utilizar o arquivo que anexei por ultimo, nele tem a correção que será subida para o SVN.

O código acima é suportado tanto pelo delphi 7, quanto pelo Lazarus ou superior, sem necessidade de diretiva de compilação, o que o torna melhor. E a diretiva de compilação no Delphi 7 ele consideraria os espaços, o que tornaria uma solução para todos menos para o Delphi 7.

Rodrigo, verifica se você está de acordo com o código abaixo na imagem acredito essa ser a solução mais simples possível Porém não sei se o Lazarus tem a constante "sLineBreak", mas se não tiver é só utilizar uma própria que já existe nos arquivos da acbr que não lembro o nome do arquivo. (LineBreak = '#10#13'); Arquivo em anexo. ACBrEPCImportar.pas

Talvez se alterar para um código nativo em pascal, sem usar a classe TStringList para a quebra de colunas.

Isso é bem estranho, pois já usei StrictDelimiter no Delphi 7, talvez é devido a versão do delphi ou update, o lazarus mesmo entende essa propriedade perfeitamente.

Verifique neste fórum, tem um tópico recente sobre a atualização dos links do webservice. Verifique no site da sefaz qual será o dia que o webservice de download direto de nfe deixara de funcionar.

Algumas notas que estou manifestando, mesmo depois de 5 horas, não está vindo o xml, acredito que seja algum problema com o ES.

Prezados, só a título de conhecimento, qual o tempo médio para receber as NFe completas após o manifesto ? Alguns clientes estão tendo que aguardar mais de 60 minutos, outros não mais que 5. Nos casos de demora o cliente acaba requisitando o ultimo NSU várias vezes pelo fato da demora. Existe algum motivo específico ?

Danfe Simplificado - 1/0 páginas (3 páginas no total) Danfe Normal - 1/3 páginas (2 páginas no total) Danfe Normal Novo - 1/2 (2 páginas no total) funcionando perfeito. (/trunk/Exemplos/ACBrNFe2/Delphi/Report/DANFeRetratoNovo.fr3)

Prezados, sabemos que não é a primeira vez que existe a necessidade de correção da URL dos WebServices, e acredito que talvez não seja a ultima. Essas modificações de URL para quem utiliza uma DLL para distribuir a parte do código que diz respeito a ACBR mesmo que pouco ainda afeta alguma coisa, para os que utilizaram diretamente dentro do código fonte afeta muito mais, principalmente para quem trabalhar com lançamento de versões programadas de tempos em tempos, além de vários outros exemplos. Gostaria de sugerir e saber se acham válido, que o arquivo ACBrNFeUtil passe a utilizar um arquivo XML, INI ou TXT para armazenar as URLs, de forma OPCIONAL por meio de configuração. Nós particularmente não gostamos de realizar modificações que não possam ser enviadas ao repositório da ACBr, por isso o motivo do tópico.

Aqui no ES a homologação não está funcionando, eu fiz os testes com as novas url para o SVRS e ficou assim: Antigas: Produção = OK; Homologação = OFF Novas: Produção = OK; Homologação = OK (24-04-2015 11:40);

Pois é, eu usei um arquivo que peguei no 4Shared, olhando aqui no manual, o padrão é DDMMYYYY. A informação pode ser confirmada na página 18 do manual que contem a seguinte informação Correção: Result := EncodeDate(StrToInt(Copy(S, 5, 4)), StrToInt(Copy(S, 3, 2)),StrToInt(Copy(S, 1, 2))) Obrigado pela colaboração Rodrigo.

Qual o problema que você encontrou ? agora que o componente foi enviado, estou com ele pelo repositório do SVN da ACBr, e aqui para mim está compilando normalmente. Gostaria de pedir para removerem o procedimento inicializa, pois quando foi criado, não era utilizada a herança do procedimento base, agora ele não é mais necessário. [dcc32 Hint] ACBrSpedPCImportar_Base.pas(58): H2219 Private symbol 'Inicializa' declared but never used Depois quando estiver com mais tempo, vou tentar fazer uma demo e anexar aqui no tópico, eu estava testando o componente lendo um arquivo e pedindo para a acbr gerar o arquivo que foi lido, e então dar diff no tortoise para conferir as diferenças. Eu ainda não estou utilizando o componente porque estamos com outros projetos em andamento, mas é provável que alguns eventos novos sejam interessantes para o agrupamento dos blocos que não são de correspondência das filiais.