EvandroPG

Sobre a versão do monitor, não posso dizer com certeza pois não faço parte do projeto, mas no último mês estive fazendo uma adaptação nele para rodar com Indy10, para poder compilar no XE2, e com isso tenho atualizado constantemente, no SVN a ultima versão está em 0.7.7, e no fim de dezembro a versão era 0.8.1, o depois de um certo update no svn ele regrediu para 0.7.4, o que deu a entender é que, devido a não ter grandes alterações no monitor em relação ao 0.7.2 (desta que foi para o 0.8.1), voltaram a numeração superior, já que se trata de 3 dígitos, não seria uma boa prática pular para 0.8 sem ter grandes alterações, ao contrário de quando a versão era 0.6 (sem ser por eventos) e passou para 0.7 (por eventos). Se esta minha lógica estiver correta e tiver sido de fato foi o que aconteceu, acho que teria sido a decisão correta quanto a padrões de versionamento.

Quando me referi a migração futura, seria da IDE VS para alguma outra no caso do desenvolvimento para Win8 RT, já que é a única com suporte a mais de 6 meses no momento, e vai continuar assim por um tempo, me referi a isso a ser a grande vantagem do VS em relação a outras IDE, de resto continuo achando por exemplo muito mais simples desenvolver em Eclipse para Android. Quanto ao plugin que você mencionou, sim este é um diferencial para poder no momento desenvolver para duas plataformas mobile com uma única IDE e código fonte, porém como o Regys disse, o Rad Studio Mobile fará a mesma coisa diretamente a partir da IDE, mesmo fonte, 3 plataformas diferentes, e como já fazia isto desde o XE2 com o Firemonkey, porém apenas MacOS, iOS e Windows, e agora o suporte a plataformas será extendido com Android e Windows Phone. Me interessei sobre esse plugin que você mencionou, acho que estarei testando ele em breve, porém, devido ao que comentei acima, sobre o suporte a multiplataformas já existir com o Firemonkey a mais tempo e agora sendo ampliado, e pelo Rad Studio Mobile se tratar de uma IDE e não apenas de um plugin, acho que ele terá uma ampla vantagem de recursos no seu lançamento.

O XE3 tem apenas suporte a interface Metro UI, o que possibilita criar uma aplicação com o visual da nova interface do Windows 8 para as versões que não são runtime, mas falta bibliotecas com as APIs do Win8 RT. Atualmente o desenvolvimento de um aplicativo para dispositivo móvel com win8 RT está fechado no Visual Studio até onde tinha visto pela ultima vez (Dezembro de 2012).

Concordo que a Embarcadero tem um longo caminho, mas não acho que após o lançamento do Rad Studio Mobile demore tanto tempo para ter uma ótima IDE para desenvolvimento mobile. E tambem não concordo quanto ao VS ser a unica solução para mobile pronta realmente boa no momento, dado que a integração do Android com o Eclipse por exemplo é muito melhor do que com qualquer outra IDE, desde coisas mais bobas como não precisar criar manualmente um layout para cada atividade nova, a até partes mais complexas. O grande diferencial do VS hoje mesmo é o desenvolvimento para Windows 8 RT, já que é a única IDE com suporte, o que HOJE realmente é um diferencial, pois sai na frente nessa plataforma, e depois de desenvolvido um aplicativo comercial nele, as chances são mínimas de uma migração futura, dependendo apenas do sucesso do Windows 8 RT mesmo.

Não tinha visto que o roadmap havia sido atualizado com uma data para desenvolvimento para windows phone, esta é uma excelente notícia, só me deixa ainda mais empolgado com o produto, ainda mais agora que acertei o início da minha pós graduação em aplicativos móveis e computação em núvem para março, certamente será um produto que vou adquirir.

Sim, lidei bastante com o Firemonkey no XE3 que foi o que me dispertou o interesse, e ao saber do Rad Studio Mobile fiquei ainda mais interessado pelo desenvolvimento android, mas podia jurar que tinha visto em algum lugar que a compilação poderia ser feita toda em windows, haviam mencionado algo sobre incluir bibliotecas que fossem tornar isto possível, mas achei muito milagroso mesmo além de claro, ter este problema conforme você citou para desenvolver para a AppleStore, obrigado por tirar a minha dúvida quanto a isso. Sobre a pergunta de ser todo desenvolvido em Firemonkey foi por pensar que talvez o Rad Studio Mobile tivesse alguma nova palheta de componentes que agisse semelhante ao Firemonkey, mas no fim ele é todo baseado nele então, o que pelo menos para mim é uma excelente notícia, só espero que até o fim do ano a Microsoft abra para os seus parceiros o desenvolvimento para o Windows 8 RT, pois no momento está muito interessante o desenvolvimento em Metro UI no XE3, mas não vejo muita vantagem em utilizar o mesmo sem o suporte ao W8 RT.

Regys, uma dúvida, você disse que para compilar para ios ainda está sendo necessário um sistema mac com Xcode, mas será que isto será mudado nas próximas versões? Pois inicialmente a proposta deles seria que o Rad Studio Mobile compilaria para android e para ios nativamente, sem a necessidade de ser compilado em outros ambientes que não fossem o Windows, e por esse motivo inclusive que ele havia chamado a minha atenção, se você procurar por essa informação no site da embarcadero eles mencionavam sobre ser nativo o desenvolvimento. Outra coisa, o Firemonkey está disponível no Rad Studio Mobile? Ou o desenvolvimento todo é baseado nele mesmo?

OBS: Descobri só agora, poís até então não tinha lembrado de testar, que o funcionamento por socket (TCP) não está funcionando, apenas o modo TXT. Estarei dando uma olhada nisso assim que tiver um tempo.

Outra coisa, caso seja de interesse de alguem de como foi feito a migração da parte do Indy, um dos sites usados para referencia foi este http://conferences.embarcadero.com/article/32160 . Uma coisa interessante logo pelo começo é onde ele ensina a ter ambos as versões do Indy ao mesmo tempo, o que não testei, mas que pode ser que permita compilar o código original sem modificações. O link para o tópico do ACBrNFeMonitor normal para Indy 10 é este .

Juliomar, encontrei no código uma parte com algum risco de gerar um access violation, dentro do processor LerIni, ele configura a DANFe e existe uma verificação se ela está setada, if DANFe <> nil then, e um pouco mais abaixo existe a configuração da DACTe, aonde não foi feito esta mesma veirificação, o que acabou por gerar um acces violation aqui por estar sem o rave na minha IDE, porém creio que seria interessante inserir a mesma verificação da DANFe para o DACTe. Bom, segue em anexo os fontes compilando com Indy10 (Delphi 2010, XE, XE2, XE3). Erros no momento: Graças ao .ini que venho com os códigos do Juliomar, que estava configurado para rodar por socket (TCP) ao invés de arquivos txt, percebi que após a migração esta opção não funciona, estarei dando uma olhada nela assim que tiver um tempo, a prioridade é no modo TXT aqui na minha empresa no momento. OBS: Como fiz no ACBrNFeMonitor normal, removi os componentes rave por não ter o mesmo intalado aqui na minha IDE, com isso a impressão ficou desabilitada, mas é fácil de reinserir os códigos, fazendo uma comparação com o código original, pelo SVN ou caso ainda não esteja no repositório usando o WinMerge ou algo parecido. Outra observação, assim como já mencionado no ACBrNFeMonitor, estive com problemas nas funções StringToFloatDef e StringToFloat em ACBrUtil, quando o sistema não encontrava a linha no arquivo IniRec, ao entrar nessas funções o valor de NumString era '', mas ao inves de dar erro e cair no except e voltar o valor default, o compilador dava erro de conversão ignorando o except, tentei de várias formas e nada, e nem ao menos entendi a real razão do problema, por conta disso precisei contornar o problema atribuindo em StringToFloat o valor de '0' para a variavel NumString caso a mesma fosse de valor '', e ao retornar para a função StringToFloatDef, troquei o except por um finally, aonde ao verificar o valor 0, ele usaria o valor default, resolveu o problema para testar as funcionalidades, porém está extremamente errado, e gostaria da ajuda de vocês para resolver esta situação. Espero que tenha dado para entender esta parte do problema. Abaixo como contornei a situação citada acima no ACBrUtil, e a qual preciso de ajuda: Function StringToFloatDef( const NumString : String ; const DefaultValue : Double ) : Double ; begin try Result := StringToFloat( NumString ) ; finally if (Result = 0) and (NumString = '') then Result := DefaultValue ; end ; end ; Function StringToFloat( NumString : String ) : Double ; begin NumString := Trim( NumString ) ; if DecimalSeparator <> '.' then NumString := StringReplace(NumString,'.',DecimalSeparator,[rfReplaceAll]) ; if DecimalSeparator <> ',' then NumString := StringReplace(NumString,',',DecimalSeparator,[rfReplaceAll]) ; if NumString = '' then NumString := '0'; Result := StrToFloat(NumString) end ; MonitorCTe.rar MonitorCTe.rar

Qual versão do delphi está tentando usar?

O Smart Mobile Studio vai ser sensacional, iria fazer o meu TCC em cima dele, mas infelizmente devido ao atraso da versão android (previsão que para ios já esteja disponível para o primeiro trimestre, e para android pelo meio do ano), acabei desistindo.

Filman A integração com o ACBrNFeMonitor é simples e sem segredo, e pode ser utilizado independente da linguagem. Tudo que é necessário para o uso do monitor é a geração de arquivos textos com os respectivos comandos, você vai gerar normalmente o seu XML da NFe pelo seu software, e após isso gerar um arquivo texto com os comandos para envio, etc, passando os XMLs com eles.

Sei como é isso, e como é de interesse da empresa que trabalho estou com uma boa liberdade para lidar com o ACBrNFeMonitor nestas próximas semanas por aqui mesmo, e vou estar trabalhando a partir dos seus fontes agora, pois é de interesse o CT-e junto ao monitor, então pode contar com meu feedback em caso de algum problema com o CT-e no monitor!

Efetuei a migração e disponibiizei aqui, Porém não obtive nenhum feedback ainda, se puder dar uma ajuda quanto a isto e efetuar testes, agradeço. Vale lembrar que removi nesta migração a parte da DANFE, pois não tenho o rave instalado e não usamos a impressão do monitor, mas como mencionei no tópico pode-se voltar toda esta parte do DANFE sem nenhuma dificuldade através de um simples diff no SVN.