Graymalkin

Hummm... entendi melhor agora. Não existe um "protocolo" (oficial ou criado) que descreva como deve ser a comunicação entre o servidor e o cliente? Se existisse algo assim, seria apenas uma questão de implementar o protocolo em uma determinada linguagem. Abraços, Graymalkin

Um "firmware" é um software gravado em uma memória ROM (um chip, ou um circuíto integrado). Esse "software" é que controla ou inicializa o dispositivo e ele já vem gravado pelo fabricante (daí, o "firm", de "firma"). Seu computador, por exemplo, tem um firmware que é o BIOS, que permite o reconhecimento de dispositivos de massa (discos rígidos, drive de 1.44, CD-ROMs, etc.) através dos quais você tem como estar utilizando um sistema operacional nesse momento. Se você tem internet banda-larga, provavelmente tem um modem ADSL, que por sua vez também tem um firmware. Aliás, acredito que quase todos os eletrônicos de hoje em dia possuem firmwares (como o celular, por exemplo). Certo? Graymalkin

Sim, pode. Eu, particularmente, sempre coloco a conexão em um módulo e os recordsets nos forms (afinal de contas, a conexão pode ficar aberta o tempo todo, mas os recordset vão variar de um form para outro então, a nível de performance, não é recomendável manter recordsets abertos que não estejam sendo utilizados). Que eu saiba não tem como. Afinal de contas, cada Recordset é um objeto e não existe uma ligação entre eles (ou uma coleção deles). Entretanto, nada impediria que você fizesse uma coleção de recordsets e depois fechasse todos eles através de um For Each... Next. Supondo que você tenha uma coleção em um módulo... Dim coleção As New Collection ... e que você adicione nela os objetos ADODB.Recordset que estão abertos... coleção.Add rs coleção.Add rs2 ... você poderia depois fechar todos assim: For Each recset In coleção If recset.State = adStateOpen Then recset.Close End If Next Abraços, Graymalkin

Pode ser uma variável normal (dê uma olhada na resposta abaixo). Não, eu disse para você chamar o método Write() do BinaryWriter para cada byte. Abraços, Graymalkin

Aqui você encontra um exemplo disso: http://delphi.about.com/library/weekly/aa102505a.htm Abraços, Graymalkin

Raramente eu uso ASP.NET, por isso não posso te dar muitas informações sobre a HTMLTable. Bom, se você sabe popular um DataSet ou uma DataTable, basta então pegar esses dados e jogar aí para a HTMLTable como você fez nesse primeiro post, não? Abraços, Graymalkin

Conseguiu resolver? Abraços, Graymalkin

Aí... eu vi que tem que ter uma página de agradecimentos na documentação do projeto... então, vou querer ver meu nome lá!!!! Hehehehehehe... brincadeirinha, mano! Você deve estar numa correria só com esse negócio (se eu estou ficando maluco com o meu aqui, imagina você, que tem que entregar essa semana...). Bom, boa sorte aí e qualquer coisa, 'stamos aí! Abraços, Graymalkin

Não tem como você utilizar só o compilado não? Acho que seria mais prático e seguro, não? Ao invés de ter o fonte do controle no seu projeto você teria a DLL dele separada (que fica lá na pasta bin) e teria uma referência para ela. Abraços, Graymalkin

Criar cria... só que você tem que utilizar as funções da API do Windows. Eu só uso C++ para console mesmo, então não pensei que isso fosse ser um problema. Então, experimente, no Visual Studio mesmo, criar um projeto ATL ou MFC ou Win32 (ou qualquer outro que *não* seja .NET) e tenta colocar seus códigos nele. Abraços, Graymalkin

Hehehehe... é, tá ficando pior. Experimente importar "SASBasic.MenuControl" nessa página e veja se faz alguma diferença. Abraços, Graymalkin

Não pode ser problema de namespace não, né? Achei estranho que no primeiro ele coloca "SASBasic.MenuControl.ccMenu" já no segundo ele coloca só "MenuControl.ccMenu". Graymalkin

Se você estiver no Windows, experimente a função timeGetTime() que está definida no arquivo winmm.h (do Dev). Talvez com ela dê certo. Abraços, Graymalkin

Brother William, nem precisa de fazer o que eu falei. No API-Guide (http://www.allapi.net/ ou http://www.mentalis.org/) tem um exemplo de como criar uma opção e criar um callback para ela. Esse callback é uma função que será chamada quando a opção for ativada (como se fosse um evento). Abraços, Graymalkin

Acredito que essas linguagens sejam chamadas de convencionais (nunca tinha visto esse termo nesse sentido...) justamente por terem um tipo de objeto muito rudimentar (que é a estrutura, um tipo de dados definido pelo usuário). Não conheço Ada nem Modula-2, mas VB se encaixa nessa categoria. Estas nem é necessário comentar. Mas no paragráfo abaixo eu vou fazer uma observação sobre estas linguagens, relacionando com a sua pergunta. O conceito de OO é meio relativo, mas existe um certo consenso de que uma linguagem que possua tais características seja OO. Agora vem a observação sobre as linguagens acima e sobre os níveis de OO. C++, Java e Object Pascal ainda mantêm tipos primitivos (int, char, double, real, etc.) em contraste com SmallTalk, Ruby e Python, por exemplo, onde todos os tipos de dados são objetos. SmallTalk vai mais além ainda, e estruturas como if, for, etc. são métodos dos objetos (Ruby também faz isso parcialmente). Não é um quesito fundalmental que todos os tipos de dados sejam objetos, mas acredito que uma linguagem que seja assim seja mais concisa no conceito de OO (por isso que estou adorando VB.NET!) do que linguagens híbridas (C++ e Java), por exemplo. Abraços, Graymalkin

Sim, você *não* criou um objeto ADODB.Connection aqui: Function VerificaTabela(nomeTabela As String) Dim oRs As ADODB.Recordset Dim oCo As ADODB.Connection Set oRs = New ADODB.Recordset Set oRs = oCo.OpenSchema(adSchemaTables) ... Note a utilização do oCo sem a criação de um objeto (utilizando o operador New). Se você possuir um oCo global (em um módulo, ou no General Declarations de um form), esse oCo declarado dentro da rotina "sombreia" ele (ou seja, é esse local que vale na rotina). Se sua intenção é utilizar esse outro que já foi inicializado, retire a declaração de oCo da rotina. Abraços, Graymalkin

Eu também utilizei essas bibliotecas no Dev-C++ ao executar aquele exemplo ali. Abraços, Graymalkin

Se não me engano, essa "stdafx.h" é a biblioteca standard do Managed C++. Por que você não experimenta esse código em um compilador C++ como o Mingw ou o Borland? Experimente no Dev-C++: http://www.bloodshed.net Talvez você tenha mais sucesso com um desses do que o VC++ da .NET. Abraços, Graymalkin

Tem uma função chamada CreatePolygonRgn. Dê uma olhada no API-Guide (http://www.allapi.net/ ou http://www.mentalis.org/) para um exemplo dela. Abraços, Graymalkin

É, foi isso que me levou a desistir do Crystal também. Estou fazendo um projeto Orientado a Objetos, então não existe uma conexão propriamente dita com o banco de dados (sim, ela existe, mas é transparente). Essa dependência do Crystal por um bd me levou a utilizar o Report do EOliv. Abraços, Graymalkin

É só você chamar a procedure do Click do popmenu. Se a opção se chama "pagamentodacontaselecionada" deve ser algo assim: pagamentodacontaselecionadaClick(Sender); Certo? Graymalkin

Ah, sim, aquele código-fonte lá está com alguns errinhos. É PrintPreview ao invés de Preview. Além disso, é "AddColumn" ao invés de "AddColum". Abraços, Graymalkin

Não seria impossível. Existem algumas possibilidades para isso: 1ª) um programa criado em VB poderia ser capaz de gerar um firmware para ser gravado no braço; 2ª) o hardware do braço seria capaz de executar instruções em VB (esse eu acho extremamente difícil de ser, pois implica em um sem-número de fatores). Abraços, Graymalkin

Talvez realmente não seja possível, se o jogo não estiver esperando por isso. Ai tipo, Ta, ele vai receber o packet...mais de onde? Tipo, como o VB vai saber que eu quero receber exclusivamente as informações que vem da tela de login do jogo. Ele não sabe, e nem o PacketX. Veja mais abaixo. A idéia do PacketX é interceptar *toda* a comunicação via rede. Por isso é possível fazer um firewall, por exemplo, com ele. Não há como você especificar o que quer, já que quando um pacote é enviado de e para a placa de rede (ou modem) não existe qualquer classificação desse tipo. Os dados são empacotados e enviados para um destino. As informações são quebradas em pedaços (que são justamente os pacotes) por isso você dificilmente verá algo muito consistente. Seria necessário acumular uma certa quantidade de pacotes e juntá-los para ver se dá pra ver algo razoavelmente reconhecível. Particularmente ainda não utilizei o PacketX, mas meus conhecimentos de rede me levam a crer isso. Não estou com tempo atualmente, mas assim que puder vou dar uma olhada nesse PacketX (ele realmente parece interessante). Certo? Graymalkin

Se o jogo estiver operando em uma determinada porta, o que o programa pode fazer é se *conectar* a essa porta ("quem" está escutando, no caso, é o jogo). A partir daí, pode tanto o programa enviar dados para o jogo quanto o jogo enviar dados para o programa. A comunicação via sockets é mão-dupla, a partir do momento em que a conexão foi estabelecida. Abraços, Graymalkin