FabricioAraujo

Resumindo, Ambiente da DLL: Delphi XE. Ambiente de ACBr.NET: Visual Studio 2010 Pro. Dll linkada com StdCall importada com Charset.Unicode: Ok Dll linkada com StdCall importada sem Charset.Unicode: Stringbuilders preechidos apenas com o 1o char da string. Dll linkada Cdecl: "PInvokeStackImbalance" São os resultados que eu consigo aqui. Agora tem um StackOverflow no ACBr.NET.ECF.VendeItem que parece vir da DLL... Mas isso não é para este post... Amanhã eu crio o post para esse problema.

Simples: "PInvokeStackImbalance was detected". Se compilar em StdCall, esse erro some e dá para começar a trabalhar. Se eu conseguisse funcionar aqui sem StdCall no import. Acabei de recompilar com Cdecl (acertando o ACBRDll.cs de acordo), rebuild na solution do C# e rodar o ECFteste. Resultado: "PInvokeStackImbalance was detected"

Respondendo ao meu próprio questionamento: o problema estava no DLLImport. Em vez de: [DllImport("ACBr32.dll", CallingConvention= CallingConvention.StdCall)] Tem que ser: [DllImport("ACBr32.dll", CallingConvention= CallingConvention.StdCall), Charset=Charset.Unicode] Reparem o Charset=Charset.Unicode - sem ele não funfa. Tive de incluir o charset em todas as chamadas DLLImport no ACBrDLL.cs...

Boa noite, Cá estou eu para pertubar novamente Estou usando a ACBR32.dll e ACBR.NET. A DLL foi compilada para STDCALL e a acbrDll.cs foi modificada de acordo. Estou com um problema estranho: quando ocorre um erro, a ACBR.NET só consegue trazer o 1o caracter. Pensei que fosse no lado do Delphi, mas debugando a DLL nada de errado acontece e a delelê retorna o pchar corretamente (digamos que seja "Modelo não configurado" o conteúdo do buffer). No Acbr.net.ECFTest só aparece 'M' . Não sei o que é, pois o DLLImport parece certo e a função getString também parece correta... Mas deve ter algo que eu não estou fazendo certo aqui. Ambiente: Delphi XE Visual Studio 2010 pro VSPE (emulador de serial) Emulador da Bematech

Desculpe a demora, era um pequeno problema entre a cadeira e o teclado mesmo - quando eu finalmente fiz o Delphi (no Lazarus eu desisti quando vi que era impossível atachar um processo) jogar a dll no lugar certo consegui debugar. Valeu.

Usando Delphi XE não estou conseguindo debugar a DLL quando processo host é ECFTeste (Acbr.Net). Os breakpoints não aparecem de jeito nenhum. Alguém sabe o pulo do gato?

Hm?? Bastaria distribuir as dcus - já que os pacotes seriam compilados pela mesma versão do compilador - que o suporte a pacotes estáticos seria factível.

Touché. Simples: pacotes distribuídos COM O LAZARUS seriam estáticos (afinal, fazem parte da distribuição). Quem quisesse instalar outras coisa, escolhe o tipo de instalação.

Costumo dizer que problemas com componentes costumam ser 99% relacionados com a palavra PATH - em suas derivações: Windows Path, Library Path e Search Path. Raramente uso a última, altero a minha library para o ambiente da versão e a System customizo para cada versão (com a PATH padrão tendo a config do D2010). Eles podiam tornar isso mais fácil no Delphi, concordo, mas está longe de ser física quântica. Mas tudo isso foi antes de eu ficar íntimo do VMWare Player.... Curiosamente era a mesma desculpa que o pessoal do Linux dava antigamente para ter que recompilar kernel toda vez que se instala um driver. Por isso me desinteressei do Linux anos atrás - lá por volta do início do século atual... Pacotes são dependências externas. O Delphi fez o certo no D3 e os pacotes viraram dependências externas de fato. E sinceramente recompilar a IDE (que é o "kernel" do ambiente de desenvolvimento) para instalar uma dependência externa (ou "driver") não me agrada.

Então somos dois perdidos. No meu note, eu tenho delphi - mas no ambiente de trabalho onde eu estou usando ACBr preciso usar Lazarus (trabalho em 2 lugares, um usa Delphi e outro dotNet - o Lazarus está no trabalho em dotNet). Hoje estou escrevendo do note. Sugiro tirar esse $DEFINE STDCALL da propriedade do projeto e criar um ACBR32DLL.INC (tal como existe no ACBr principal). Até lá, me viro com o $UNDEF no arquivo lpr - parece que todo o projeto está seguindo, não preciso copiar isso em todos os fontes da DLL.

Não fui claro, pelo visto. Eu não sei xongas de Lazarus (que é o que posso usar aqui), e não tenho Delphi (quem dera ) onde eu estou usando a ACBr - entao estou usando Lazarus. E outra: o ACBr32.dll já está com o símbolo STDCALL definido. Coloquei um $UNDEF para remover o símbolo (gambiarra) - porque não achei onde essa goiaba está definida. O "Find in Files..." do Lazarus nada encontrou - de todas as linhas (10000+) onde existe um STDCall definido na ACBr, nenhuma delas é um $DEFINE. Como eu não quero bagunçar o coreto, onde está esse {$DEFINE STDCALL} para que eu possa comentá-lo e fazer a alteração da maneira que foi imaginada por vocês?

Onde o define para convenção de chamada STDCALL do Acbr32.dll? Já dei find in sources na base de código inteira, e nem sinal. O arquivo de importação do C# está usando cdecl para importar e isso está dando pau direto pois a DLL está sendo compilada como STDCALL. Ambiente (nativo): Lazarus 0.9.30 Ambiente (dotNet): Visual Studio 2010 (C#)

Um pouquinho mais esperto que o D1-D2 nisso. Se desse alguma craca tinha que reinstalar. ou reinstalar um backup manual do COMPLIB.DCL antes de instalar componentes. Só ficou realmente bom depois dos pacotes dinâmicos (D3 em diante).

Pelo que entendi, no Lazarus se alguém quiser instalar um componente na pallete significa que o binário da IDE tem que ser recriado (ou seja, tem que recompilar a IDE). No Delphi, se algum pacote fizer alguma besteira no ambiente, uso o regedit e removo o pacote. Nada do pacote em tempo de design sobra e o BDS.exe executa direitinho e pimpão - exetamente igual quando executou a primeira vez. Se isso ocorrer no Lazarus, o executável foi pro saco. Ou seja, tem que fazer backup antes de instalar qualquer coisa no Lazarus. É o mesmo princípio que eu sempre odiei no Linux: preciso instalar um driver? Recompila o kernel! (No Linux, acho que isso já mudou). Entendi errado? Alguém já teve problema com isso?

@EMBarbosa, IMplementar no ACBr. São modelos que ainda não são suportados @Lampada, Valeu Lampada!! Era o que eu precisava! @Daniel, Certamente precisarei da tua ajuda aqui no fórum. Valeu!!