s3c

Print Screen foi só um exemplo para ver se o código funciona. Qualquer imagem copiada p/ área de transferência, o clipboard fica com o formato CF_PICTURE. você não queria colar a imagem quando o DBImage ganhasse o foco? Pois bem, coloque aquele código no evento onKeyPress do DBImage. Não precisa setar o KeyPreview do Form porque é o DBImage que "verá" a tecla digitada.

Query como detalhe de um Table? Não entendí. Esse Table é o componente TTable ou a tabela no banco de dados?

Ah sim Arlon, mas pensei que ele queria em tempo de execução.

Veja a Api SHFileOperation e o parâmetro TSHFileOpStruct

#22 equivale Ctrl+v(paste,colar). Tente o seguinte: Aperte a tecla Print Screen Foque o DBImage e aperte Ctrl+v

Ou Select bla bla bla From Tabela Where Upper(Campo) Like 'AR%' Select bla bla bla From Tabela Where Upper(Campo) Like '%AR' Select bla bla bla From Tabela Where Upper(Campo) Like '%AR%' AR% - Que comece c/ AR %AR - Que termine c/ AR %AR% - Que contenha AR

Grande alma !!! Isso mesmo BRIGADÃO !!!

Alguém por acaso saberia como deixar o form sempre no foco?

TTabSheet.Caption := 'Mudei o Caption'; P/ criar: var TS:TTabSheet; TS := TTabSheet.Create(Self); TS.Caption := 'Caption da nova tabsheet'; TS.PageControl := PageControl1; // é aqui que você a insere na PageControl.

Estouro de pilha. Ex disso é uma recursão indefinida.

porque você não copia no padrão Windows? Ele já coloca a barra de progresso.

porque você não multiplica todos os denominadores; depois vá simplificando dividindo o resultado por números primos e veja se cabe na frações utilizando o mod. Quando o mod retornar > 0, então o último resultado é o mmc.

Bom, eu utilizo o InstallShield 7. Ele possui eventos que você deve entender: onBegin // é sempre chamado onFirstUIBefore // é chamado somente na instalação do produto onFirstUIAfter onMaintUIBefore // é chamado somente na manutenção do produto onMaintUIAfter onCanceling // é sempre chamado no cancelamento e assim por diante... Em cada evento você pode inserir código p/ efetuar as ações necessárias; para isso você deve conhecer um pouquinho de C, pois seus scripts são nessa linguagem. Agora se for aquele que vem c/ o Delphi, eu já não saberia te dizer porque nunca utilizei, mas deve ser semelhante ao outro.

Ops: Não é uses CliBoard, mas sim: uses ClipBrd;

uses ClipBoard; procedure TForm1.DBImage1KeyPress(Sender: TObject; var Key: Char); begin if (Key = #22) and Clipboard.HasFormat(CF_PICTURE) then begin DBImage1.Picture.Assign(Clipboard); DBImage1.Stretch := true; DBImage1.Refresh; end; end; Obs: O picture será um TBitmap; se quiser modificá-lo p/ Jpeg(menor espaço), também é possível.

Não, na rotina do Arlon checa somente que se o valor for digitado. E se não digitar?

Mas e se não digitar e simplemente atribuir o valor à propriedade Text Edit.Text := 'Qualquer valor'; ?

você tem que converter. Label1.Caption é um tipo String. você não pode jogar um número numa string; Faça assim: Label1.Caption := IntToStr(numero - 1);

Banco de Dados. Como chegar às 3 camadas. Olá colegas deste fórum. Não sei se são propriamente dicas, mas acho que vale a pena ler e, por favor me contestem para eu poder aprender. Notei aqui que a grande maioria utiliza sistemas de duas camadas ou client/server, ou seja, para cada pc acessando o sistema, haverá no mínimo uma conexão ao banco de dados; com isto a aplicação fica repleta de componentes sql como databases, tables e querys. Vale lembrar que em muitas aplicações client/server não é possível conectar-se ao banco de dados via internet. Dica n.1: Esqueçam os componentes TTable e utilizem TQuery. Com isto vocês serão forçados a aprender e utilizar comandos sql. Dica n.2: Esqueçam o TDataModule e não coloquem componentes sql em tempo de projeto. Crie-os e libere-os conforme a necessidade em tempo de execução. Isto dará mais noção à orientação a objetos que é realmente como o Delphi trabalha e otimizará recursos de memória. Dica n.3: Não deixem os parâmetros de conexão ao banco de dados fixos dentro da aplicação e sim externos como no registro do Windows por exemplo. Dica n.4: Criem uma classe de conexão numa unit separada com funções que retornam objetos de conexão e objetos de acesso aos dados; por ex: BDE retorna Tdatabase e Tquery DBExpress retorna Tsqlconnection e Tsqlquery ou TsqlclientDataSet InterbaseExpress retorna Tibdatabase e Tibquery ou TibclientDataSet Etc... Retornem para a aplicação a classe ancestral e, se houverem métodos próprios da classe filha, utilizem o Cast. No caso de conexão retornem TCustomConnection. No caso de acesso aos dados, retornem TDataset. Pois todas elas derivam destas classes. Com isto a aplicação fica mais enxuta e não implicará em grandes mudanças no caso de mudança de banco de dados ou meio de acesso. Lembro aqui que perdí ± 3 meses com testes em conexão ADO(Activex Data Object) e desistí porque como este tipo de conexão utiliza automação OLE Variant, a performance caiu consideravelmente em relação ao BDE. Dica n.5: Após serem efetuadas as 4 etapas acima, o próximo passo é criar um servidor de banco de dados para desenvolvimento de sistemas em 3 camadas, onde a aplicação cliente ficará livre dos componentes sql e TDBs que serão substituidos por componentes Socket e TCP/IP para conexão com o servidor. Com isto não importa onde o banco esteja, pode ser na mesma máquina, numa intranet, internet, ou qualquer outra rede que entenda o protocolo TCP/IP. Minha próxima dica seria como criar um objeto de manipulação e transporte de dados para comunicação entre cliente e servidor, mas não sei se seria muito útil escrevê-la neste momento. Bom, espero que tenha sido de alguma serventia para alguém e também espero ser contestado no fórum para sempre aprender e corrigir meus erros. Obrigado a todos!!!

Eu ía postar na seção de dicas, mas ao invés de clicar em "respoder" cliquei em novo tópico. Tentarei novamente.

Olá colegas deste fórum. Não sei se são propriamente dicas, mas acho que vale a pena ler e, por favor me contestem para eu poder aprender. Notei aqui que a grande maioria utiliza sistemas de duas camadas ou client/server, ou seja, para cada pc acessando o sistema, haverá no mínimo uma conexão ao banco de dados; com isto a aplicação fica repleta de componentes sql como databases, tables e querys. Vale lembrar que em muitas aplicações client/server não é possível conectar-se ao banco de dados via internet. Dica n.1: Esqueçam os componentes TTable e utilizem TQuery. Com isto vocês serão forçados a aprender e utilizar comandos sql. Dica n.2: Esqueçam o TDataModule e não coloquem componentes sql em tempo de projeto. Crie-os e libere-os conforme a necessidade em tempo de execução. Isto dará mais noção à orientação a objetos que é realmente como o Delphi trabalha e otimizará recursos de memória. Dica n.3: Não deixem os parâmetros de conexão ao banco de dados fixos dentro da aplicação e sim externos como no registro do Windows por exemplo. Dica n.4: Criem uma classe de conexão numa unit separada com funções que retornam objetos de conexão e objetos de acesso aos dados; por ex: BDE retorna Tdatabase e Tquery DBExpress retorna Tsqlconnection e Tsqlquery ou TsqlclientDataSet InterbaseExpress retorna Tibdatabase e Tibquery ou TibclientDataSet Etc... Retornem para a aplicação a classe ancestral e, se houverem métodos próprios da classe filha, utilizem o Cast. No caso de conexão retornem TCustomConnection. No caso de acesso aos dados, retornem TDataset. Pois todas elas derivam destas classes. Com isto a aplicação fica mais enxuta e não implicará em grandes mudanças no caso de mudança de banco de dados ou meio de acesso. Lembro aqui que perdí ± 3 meses com testes em conexão ADO(Activex Data Object) e desistí porque como este tipo de conexão utiliza automação OLE Variant, a performance caiu consideravelmente em relação ao BDE. Dica n.5: Após serem efetuadas as 4 etapas acima, o próximo passo é criar um servidor de banco de dados para desenvolvimento de sistemas em 3 camadas, onde a aplicação cliente ficará livre dos componentes sql e TDBs que serão substituidos por componentes Socket e TCP/IP para conexão com o servidor. Com isto não importa onde o banco esteja, pode ser na mesma máquina, numa intranet, internet, ou qualquer outra rede que entenda o protocolo TCP/IP. Minha próxima dica seria como criar um objeto de manipulação e transporte de dados para comunicação entre cliente e servidor, mas não sei se seria muito útil escrevê-la neste momento. Bom, espero que tenha sido de alguma serventia para alguém e também espero ser contestado no fórum para sempre aprender e corrigir meus erros. Obrigado a todos!!!

Mas e se ele passar pelo edit pelo <tab> e o edit estiver vazio?

Sim, ele cria índices. Como você cria tabelas no Paradox? você não utiliza comandos sql (create table, alter table, etc...)? Como seu acesso é BDE, seu código praticamente não muda e se mudar é mínima coisa como parambyname.asdate em um, parambyname.asdatetime no outro. Tenta instalá-lo e fazer uns testes. você pega o free em: www.borland.com/devsupport/interbase/opensource

é é é, o tópico não era bem uma pergunta. Eu que errei de seção.

Postei um tópico sobre conexões via Socket e Tcp/ip e o post sumiu. Alguém sabe o que houve?