Zikagames - Início Ir para conteúdo
keyboard_arrow_down
account_circle Entrar

Entrar



  • Não recomendado para computadores públicos


  • Esqueceu sua senha?

person_add Cadastre-se

Pesquisar na Comunidade

Mostrando resultados para as tags ''texto''.



Mais opções de pesquisa

  • Pesquisar por Tags

    Digite tags separadas por vírgulas
  • Pesquisar por Autor

Tipo de Conteúdo


Fóruns

  • Anúncios e novidades
    • Regras
    • Anúncios
    • Entre para a equipe Zikagames!
  • Eventos Exclusivos - Zikagames
    • Bolão do Brasileirão!
    • Sorteios Zikagames!
    • Membro do mês - Zikagames!
    • Outros eventos
  • Parceiros da Zikagames!
    • TZN SHOW!
    • Athens Graphics - DISCORD
  • Espaço do usuário
    • Apresente-se para a Zikagames!
    • Tutoriais Zikagames
    • Suporte ao usuário
    • Sugestões/Reclamações
  • FPS Zone
    • Fortnite
    • PUBG
    • CS:GO
    • Apex Legends
    • CrossFire
    • Rainbow Six
    • Outros FPS games
    • Lixeira
  • RPG/MOBA zone
    • League of Legends
    • Tibia
    • World of Warcraft
    • WYD
    • Ragnarok
    • Grand Theft Auto - GTA
    • Red Dead Redemption 2
    • Outros RPGs/MOBA em geral
    • Lixeira
  • Plataformas
    • Xbox
    • Playstation
    • iOS/Android/Portáteis
    • Retrô/Emuladores
    • Lixeira
  • Design Zone
    • Galeria DesignZone
    • Tutoriais DesignZone
    • Recursos DesignZone
    • Pedidos DesignZone
    • Suporte DesignZone
    • Bate-papo DesignZone
    • Lixeira
  • Info ZONE
    • Softwares
    • Hardwares
    • Delphi
    • Visual Basic
    • C / C++
    • JAVA
    • Javascript
    • Desenvolvimento web
    • Criações InfoZone
    • Lixeira
  • Comércio ZikaGames
    • Promoções
    • Cupons
    • Doação/Venda/Troca entre usuários
    • Bate-papo (COMÉRCIO ZG)
    • Lixeira
  • Diversos
    • Bate-papo geral
    • Entrevistas
    • Trackers
    • Análises e Reviews
    • Notícias e Novidades
    • Músicas/Vídeos
    • Lixeira

Encontrar resultados em...

Encontrar resultados que...


Data de Criação

  • Início

    FIM


Data de Atualização

  • Início

    FIM


Filtrar pelo número de...

Data de Registro

  • Início

    FIM


Grupo


Sobre


Discord


Instagram


Facebook


Twitter


Youtube

Encontrado 4 registros

  1. Hoje em dia quase todos que tem um PC tem o Discord intalado. Seja para entrar em call com seus amigos, ou para zuar em comunidades por ai. A questão é: Você sabe tudo sobre a formatação de texto no discord? Há varios segredinhos que existem para você criar um texto bem decorado, ou se você for dono de uma comunidade/servidor, escrever coisas importantes com organização. PARTE 1: Formatação em sí. Itálico: *TEXTO* Negrito: **TEXTO** Negrito Itálico:: ***TEXTO*** Sublinhado: __TEXTO__ Itálico Sublinhado: __*TEXTO*__ Negrito Sublinhado: __**TEXTO**__ Riscado: ~~TEXTO~~ PARTE 2: Blocos de código Fundo meio transparente: Envolva seu texto com um acento grave ` Fundo meio transparente com bloco básico: Envolva seu texto com três acentos graves ``` LEMBRETES: O Discord suporta linguagens como css, basta um exemplo: (três acentos graves ` + css + texto) Duvidas? Sinta-se a vontade para comentar! CREDITOS: NotyPunch (Texto, Formatação, edição nas imagens) Discord/BOT (Imagens, comandos)
  2. Parte 3! Indice: Parte 1: Clique aqui Parte 2: Clique aqui Parte 3: Clique aqui Recursos especiais do Mep Texto Pensando na praticidade… Incluí dois recursos que gosto muito e uso freqüentemente, e normalmente quem viu, gostou também. Um agiliza a inserção de textos e frases muito usados, e o outro salva periodicamente o conteúdo do editor numa pasta especial, para evitar a perda de textos quando o computador reinicia ou trava, ou cai a energia, etc. Inserção rápida de textos Nomes, endereços, assinaturas, e-mails, sites, frases… Quantas coisas repetidas as pessoas não precisam digitar, hein? Para poupar tempo do usuário, o Mep Texto pode carregar uma lista de palavras definidas pela pessoa, e inserir facilmente os textos. Basta teclar F9 ou CTRL + Espaço, na tela do editor. Veja: A lista exibirá todas as palavras ou frases cadastradas, a menos que o usuário chame-a com alguma coisa já digitada à esquerda do cursor. Neste caso, serão exibidos apenas os itens que começam com o que está digitado, filtrando as opções. As palavras e frases ficam salvas por padrão no arquivo “TextosMT.mep”, na pasta “Meus documentos” do usuário. Estando na pasta “Meus documentos”, fica fácil o backup e edição, além de ser privado e separado das outras contas de usuário do computador. Ao inicializar o editor, se esse arquivo existir, a lista é carregada automaticamente. Na primeira vez que o usuário chamar a lista, como o arquivo não existirá, o programa dará algumas orientações e criará o arquivo. Deve-se deixar cada palavra ou expressão em uma linha; não precisa definir palavras únicas, pode-se usar frases ou nomes com espaços, também. Não há limite aplicado na quantidade de itens que podem ser guardados na lista, mas quanto mais, mais memória será usada. Não é recomendável deixar com mais de 100, no geral, visto que cada aba manterá a lista carregada, na sua instância do “frmMepTexto”, o formulário do editor. Todo o trabalho é feito por um componente pronto, que acompanha o SynEdit. Na inicialização, basicamente chama-se um método do SynEdit para carregar o texto do arquivo definido. Backup Paranoia Quem nunca perdeu textos e arquivos com o computador? Seja porque o sistema travou (o que é muito comum no Windows 9x/Me), ou reiniciou sozinho (salve, Windows XP!), ou ainda por motivos de força maior, como queda de energia (se bem que os outros casos também são de força maior, né). Inicialmente eu fiquei com um pé atrás quando pensei em implantar esse recurso, pesando no desempenho, mas vale a pena. O Windows e os programas gravam muita coisa temporária, mesmo que apaguem depois, eles gravam. Gravar arquivos continuamente, especialmente arquivos pequenos, não é nenhum sufoco para o HD. Dada a facilidade na recuperação depois, inclusive de “versões anteriores” dos arquivos, decidi colocar um sistema de backup literalmente paranóico: ele fica gravando de tempos em tempos o texto do editor, num arquivo separado, numa pasta especial. Com o tempo a pasta vai ficando cheia de arquivos, mas o usuário pode limpá-la a qualquer momento, além do que, esse recurso vem desativado por padrão, ou seja, somente se o usuário quiser ele terá isso. O editor salva os backups utilizando como nome de arquivo a data e hora sem separadores (nem barra, nem dois pontos) e o nome do arquivo aberto. Como usa a hora incluindo os segundos, é praticamente impossível (pelo menos, muito raro!) de ele tentar salvar dois arquivos com o mesmo nome, ao mesmo tempo. Por padrão, a pasta de salvamento destes backups é a “Backup Mep Texto”, que fica dentro da pasta “Meus documentos” do usuário também, garantindo privacidade. Nas opções, o usuário pode escolher qualquer outra pasta. O tempo padrão é de 20 em 20 segundos, isso faz com que a pessoa perca praticamente um parágrafo pequeno, se cair a energia, por exemplo. O bom desse backup é que ele independe do arquivo aberto no editor em si, inclusive o backup será salvo mesmo se a pessoa não salvar o arquivo, apenas por abrir o editor e sair digitando. Como medida de “inteligência”, ele não salva backups de arquivos salvos não modificados (por exemplo, que a pessoa esteja apenas lendo na tela), ou se o editor estiver vazio. A pasta pode ser aberta (e/ou limpa) pelo menu “Configurar > Backup paranóia”; esse item só aparece se o backup estiver ativado nas opções. Eu já recuperei coisas importantes graças a esse recurso, alguns amigos também… Para quem usa muito um editor de textos puro, vale a pena (meu formato de arquivo preferido é o txt! Abre em qualquer lugar, é leve e pequenininho, ainda pode ser comprimido a alta taxas de compactação…). Tecnicamente é usado o tão temido “Timer”, “Temporizador”, para ficar salvando os backups. Na tela das opções há uma orientação para o usuário não definir um tempo muito baixo, pois isso poderia reduzir o desempenho do sistema, especialmente se muitas abas ou janelas estivessem abertas. Mas, para quem não gostou da idéia, há também um outro recurso importante, que faz falta no Bloco de notas: o salvamento automático do arquivo atual. Diferentemente do backup paranóia, este salva o texto do arquivo aberto no próprio arquivo, como se o usuário clicasse no botão “Salvar”. Novamente será utilizado um “Timer”, mas isso vem desativado por padrão, a pessoa tem que ativar em cada sessão ou aba do editor, toda vez que quiser: Mep Texto no Linux? Rodando ele no Linux com o Wine (testei no 0.9.25-1), vi que quase tudo funcionava a contento, dando até para usá-lo como editor no lugar do KEdit ou GEdit, sem maiores problemas. A versão testada inicialmente foi a 5.0 beta 3, com os skins (que foram aplicados na 5.0 beta 2, pois a 5.0 beta 1 já era MDI mas sem skins). Os skins não funcionaram, entendo que é complicado pra o Wine, aliás é de se admirar que ele possa funcionar. Era necessário então desativar os skins no registro, antes de abrir o Mep Texto. Pensando nisso incluí, a partir de então, na instalação, um item para o usuário selecionar, se está usando o Windows ou o Linux. Isso não é problema para o Mep Texto Open, que não usa os skins (não me refiro aos skins das barras de menus, mas sim das janelas e itens visuais da interface em si). Aproveitando, e para facilitar a compatibilidade dele no Linux sob as versões atuais do Wine, inclui uma configuração especialmente para isso. Uma variável no formulário “pai”, nomeada de “linux”, e pública para todo o projeto, para que possa ser acessada de qualquer tela. Ela é inicializada com base na opção “Linux” da chave do registro do programa, que pode ter o valor 1 (otimizado para o Linux) ou 0 (para rodar no Windows). Incluí também um item para o usuário marcar ou desmarcar isso nas opções, na aba “Outras configurações”, caso ele queira ou precise. Entre outras coisas, quando ele está “otimizado” para o Linux, estas coisas são alteradas: Na tela das opções, na aba “Associação de arquivos”, é exibida uma mensagem por cima, dizendo que a associação de arquivos não irá funcionar – pois isso no Linux dependerá da interface gráfica usada, e não do que o programa gravaria sob a chave HKEY_CLASSES_ROOT, do registro. Aliás, foi bom comentar: para alterar os itens desta aba, em tempo de desenvolvimento, clique dentro do painel da mensagem e arraste-o para algum canto, pois os botões ficam por baixo. Antes de fechar e compilar, arraste-o de volta para a posição original, cobrindo toda a tela. Ele está com a propriedade “Visible” configurada para False, mas esta é alterada para True em tempo de execução, se a opção de otimização para o Linux estiver ativa. Quando algum arquivo está aberto, o menu “Arquivo” exibe outros itens, como “Renomear”, “Excluir”, “Propriedades”, “Abrir em outro programa”, etc. Algumas destas funções não funcionaram no Wine, por usarem algumas janelas comuns da API do Windows talvez ainda não implantadas totalmente. Então estes itens são desativados também. O salvamento… Posso estar errado, mas parece ser um bug da versão 7 do Delphi. Ela inclui suporte nativo às janelas “Abrir” e “Salvar” do Windows com a barra de locais, recurso que foi implantado no Windows 2000/Me. Esse suporte não existe nativamente nas versões mais velhas do Delphi, claro, pois foram lançadas antes do Windows 2000/Me. Mas não é esse o problema. As janelas “Abrir” e “Salvar” retornam ao programa o nome do arquivo selecionado, com a extensão, e esta dependerá do item que o usuário selecionar na lista “Arquivos do tipo”. Pois bem, ela deveria retornar o nome já com a devida extensão, isso funciona na janela “Salvar” do Delphi 5. Mas nos programas compilados com o Delphi 7, ele retornava o nome sem a extensão, a menos que o usuário digitasse manualmente no campo do nome do arquivo. Então o que eu fiz, coloquei na função de salvamento uma instrução que verifica qual item na lista de tipos de arquivos foi selecionado (usando o índice do item da lista), e dependendo do número retornado, era adicionada ao final do nome do arquivo, a extensão correta. Se você modificar ou adicionar mais tipos de arquivo, deverá alterar isso também (localize o item “SFiltroSalvar” na unidade “UnitMensagens”). Pois bem, um bug unido do Delphi 7 com o Windows, digamos, rs. No entanto, no Wine, ele me retornava a extensão correta de acordo com o item selecionado pelo usuário no campo “Salvar como tipo”, isso seria o certo (parabéns, Wine :). Como eu havia programado para aplicar a extensão “manualmente” via programação, ao salvar no Wine, o arquivo ficava com duas extensões. Coloquei então um verificador, se ele estiver otimizado para o Linux, então não adiciona a extensão, deixando o nome que o Wine retornar, pois este já virá com a extensão. Existem outras pequenas modificações, como o item “Sobre o Windows” do menu “Ajuda”, que mudará para “Sobre o Wine”, etc. Para encontrar as outras mudanças, use o recurso “Find in files” do menu “Search” do Delphi, e localize por “pai.linux”. Se você definir alguma coisa útil para o Linux, que não seja para o Windows, ou vice-versa, pode usar esta variável que já está pronta e é inicializada corretamente, colocando um verificador, por exemplo: if pai.Linux then // faça coisas aqui para o Linux else // agora faça para o Windows Alguns ajustes ainda são necessários, isso se dará nos próximos releases oficiais. Entre eles está a verificação nos nomes de arquivos e abertura de pastas… Basicamente adicionar o comando “explorer” antes do nome da pasta, assim o Wine já abre num visualizador de arquivos incluso com ele (pois atualmente as pastas simplesmente não são abertas), e mudar as funções de verificação dos arquivos ou fazer alguma gambiarra… Afinal, os caminhos dos arquivos no Linux não começam com uma letra e dois pontos, como “C:arquivo.txt”, por exemplo, mas sim “/mnt/hda1/arquivo.txt”. Como as funções inclusas no Delphi são para o Windows, as que verificam nomes de arquivos esperam encontrar uma letra e dois pontos antes do nome. A função “ExtractFileName”, que retorna o nome do arquivo sem o caminho, por exemplo. Ao chamá-la assim: ExtractFileName(‘C:minhas coisasmeu arquivo.txt’); Ela me retornará uma string contendo apenas “meu arquivo.txt”. Agora, ao chamá-la desse modo: ExtractFileName(‘/mnt/hda1/minhas coisas/meu arquivo.txt’); Ela me retornará “/mnt/hda1/minhas coisas/meu arquivo.txt”, o que não é viável, pois eu queria apenas o nome do arquivo, sem o caminho. Isso é preocupante, pois com o Wine, os programas para Windows podem acessar arquivos do sistema Linux usando a nomenclatura do Linux! Alguns aplicativos reclamam, mas reclamam simplesmente porque verificam o caminho do arquivo, que é um caminho inválido para o Windows. Se o programa tentar gravar ou abrir um arquivo dando como caminho “/mnt/hda1/home/mah/.kde/AutoStart”, por exemplo, ele conseguirá, pois (pelo menos nas versões atuais) o Wine permite e entrega o arquivo correto. Verifiquei isso ao associar os arquivos de texto ao Mep Texto, sob o Wine. Ele tanto pode abrir os arquivos usando as letras mapeadas pelo Wine como o caminho no estilo Linux. Ao abrir, editar e salvar arquivos pelo editor, tudo bem. Mas… O Mep Texto não conseguia salvar o backup paranóia para o arquivo atual, se ele estivesse referenciado com o caminho no estilo Linux. Simples: no backup paranóia, o Mep Texto usa o nome do arquivo, além da data/hora. Ele pega só o nome do arquivo, não o caminho completo, usando para isso a função “ExtractFileName”, provida pelo Delphi. Mas, ao usá-la com um caminho estilo Linux, a função retorna o nome do arquivo completo, incluindo as barras. Assim o editor não consegue salvar o arquivo na pasta de backup, por conter barras no nome. O erro não irrita o usuário, pois apenas uma mensagem é exibida na barra de status, mas o ideal seria funcionar. Estou para implementar nos próximos releases, na função de salvamento do Backup Paranóia, isso: verificar o nome do arquivo e pegar a parte depois da última barra, isso seria mais garantido; substituir as barras por outro caractere qualquer que seja permitido nos nomes de arquivos, e gravar o arquivo de backup com o caminho completo (isso seria inviável, pois dependendo da pasta, o nome podeira ficar muito grande); ou encontrar uma função correspondente à “ExtractFileName” que funcione tanto para caminhos Windows como Linux. Apesar disso tudo, o Mep Texto é um programa para Windows, seguindo o formato win32/pe. O que ajuda aí é todo o poder do Wine, que vem a ser uma espécie de “subsistema Windows open source, for Linux”. Veja mais informações sobre melhorias para rodar o Mep Texto no Linux, inclusive de como associar os arquivos para abri-lo com um duplo clique como se fosse um editor “nativo”, em: http://janelasepinguins.blogspot.com/2007/05/rodando-o-mep-texto-no-linux.html Outras considerações importantes para redistribuir o projeto modificado A checagem de parâmetros passados na linha de comando para o programa é feita direto no código fonte do projeto (“MepTexto.dpr”), antes de qualquer formulário ser carregado. Para abri-lo no Delphi, use o menu “Project > View Source”, estando com o projeto já carregado. A associação de arquivos poderia ser feita pelo instalador, mas fica mais prático fazê-la pelo próprio programa, simplificando a instalação. Você precisa apenas chamar o executável com o parâmetro correto. A saber, eis os parâmetros suportados: /assoc /desassoc /ie /lic /reset Algumas imagens usadas em algumas telas do programa estão como recursos, dentro do arquivo “mt.res”, e podem ser trocadas com editores visuais de recursos, como o já comentado Resource Hacker. Abra o “mt.res” nele, localize a imagem e troque-a pela desejada. Esse arquivo não precisará ser redistribuído, pois os recursos inclusos nele serão embutidos no executável, pelo Delphi, durante a compilação. Eu incluí como recurso pois estas imagens são compartilhadas por várias telas comuns, assim uma única imagem de cada faz parte do programa, evitando colocar as mesmas imagens independentes em cada tela, o que ocuparia mais espaço. Não deixe de curiar a unit “MepUtil2.pas”, nela existem diversas funções usadas no Mep Texto, por exemplo, para escrita e leitura de dados no registro (já comentadas), para descobrir a versão de Windows utilizada, uma que retorna a pasta do Windows, outra a System, outra a Temp, etc. Se quiser, fique a vontade para usar estas funções em outros programas 🙂 Para redistribuir o programa para os usuários finais, sugiro copiar o executável compilado para a pasta “distrib”, que contém outros arquivos necessários, e então redistribuir esta pasta. Comentando agora os arquivos incluídos, como sugestão de redistribuição (e que são redistribuídos no pacote oficial): MepTexto.exe.manifest Arquivos .bat FundoMT1.bmp HTML.MEP icTxt.ico ImageRes.dll license.txt sobrew.mep ic.exe Claro que você pode remover ou alterar esses arquivos (exceto o “LICENSE.TXT”!), ou ainda adicionar novos. O melhor, no caso de Windows, seria mesmo criar um instalador, que basicamente copiasse o conteúdo dessa pasta para uma pasta do tipo “C:Arquivos de programasSeu Programa” e criasse atalhos, chamando o editor com o parâmetro “/assoc” logo no final da instalação, e chamando-o na desinstalação com “/desassoc” e depois novamente, com “/reset”. A instalação eu faço com o Mep Installer, uma versão personalizada por mim do Inno Setup (é um “fork” do Inno, basicamente, mas de código fechado). Basta usar o arquivo de extensão “.mpi” fornecido no pacote do código fonte, compilando-o no Mep Installer, para gerar o instalador. Se você quiser usar o Inno Setup, por ser de código aberto (ou por qualquer outro motivo), pode usar este mesmo arquivo, pois eles são bem compatíveis, exceto um ou outro item (mas mesmo assim bastará remover ou comentar as linhas que não funcionarem no Inno Setup). Outro instalador bom e open source é o da Nullsoft, o NSIS (sim, da mesma dona do Winamp!), mas o script de projeto dele não tem nada a ver com o do Inno e você deveria criar o instalador do zero. Nota: para quem se perguntar porque o Mep Installer é fechado, sendo baseado no Inno Setup, que é open source… Primeiro, a licença de uso do Inno não impõe esta restrição, ele não é GPL, o autor pede apenas para manter os créditos. Segundo, que sendo open source, não dá para confiar totalmente nas funções de proteção por senha ou número serial da forma como são aplicadas. Eu mudei estas funções, coloquei proteção nativa por número serial fixo, verificações redundantes, personalizei o visual com base num instalador que eu tentava desenvolver antes de conhecer o Inno, deixando a instalação super fácil para os usuários finais… Além de ter opcionalmente a interface de compilação em português 🙂 E como apliquei medidas de proteção, não quis redistribuir o código fonte; mas ele é freeware. Mesmo sendo um aplicativo de pequeno porte, digamos, mas de uso geral, eu penso muito no sistema do usuário, em respeito a eles, e espero que você aja assim como programador também. Configurações de opções? Grave sob a chave HKEY_CURRENT_USER, é mais prático e melhor. Se você gravar sob a HKEY_LOCAL_MACHINE, todos os usuários ficarão com as mesmas opções, e o pior: usuários limitados não podem gravar dados na maioria dos locais sob esta chave, o que resultará em erros exibidos ao abrir e ao fechar o editor, além de que isso provoca a saída do procedimento atual criado pelo Delphi, não carregando todas as opções posteriores ao ponto em que ocorreu o erro – ao ponto em que a chave não pôde ser gravada. Evite também gravar arquivos nas pastas do Windows ou sob a Arquivos de programas. As versões inciais do Mep Texto gravavam as configurações num arquivo INI, que ficava na pasta do programa (em alguns releases, na pasta do Windows). Como inconvenientes, além de as mesmas opções serem aplicadas a todas as contas, os usuários limitados recebiam mensagens de erro ao abrir e fechar o editor, se a partição da pasta do programa estivesse formatada em NTFS, que é o padrão no Windows. Isso simplesmente porque não teriam direito de escrita nessa pasta. Uma alternativa, caso você prefira salvar as opções num arquivo INI, é gravar o arquivo em uma pasta do usuário, como a “Application Data”, por exemplo, dentro da pasta do perfil dele. Esses caminhos podem ser encontrados no registro, para que você recupere a pasta correta (dê uma curiada na chave “HKEY_CURRENT_USER Software Microsoft Windows CurrentVersion Explorer Shell Folders”, e carregue com a função LeReg, por exemplo, para pegar o valor correto da pasta, independentemente do idioma do Windows ou da partição e local da pasta). Gravar o arquivo de configurações na mesma pasta do programa só é útil em programas que serão “móveis”, por exemplo, para rodar o editor a partir de um pen drive, sem alterar nada no computador. Uma dica caso você queira fazer isso, é alterar as funções “EscreveReg” e “LeReg”, da unit “MepUtil.pas”. Assim o programa continua chamando elas, nas inúmeras referências que tem às mesmas, mas elas redirecionariam o que seria gravado no registro para um arquivo INI. Se você fosse alterar todas as ocorrências delas, teria um trabalho absurdamente maior. Mesmo com todos esses cuidados, uma coisa será inevitável… Ao desinstalar o programa, mesmo que o desisntalador seja programado para remover arquivos de configuração nas pastas do usuário, ele removerá apenas do perfil do usuário que rodar o desinstalador. As outras contas continuarão com as chaves no registro e/ou com os arquivos no HD. No caso do registro, normalmente isso é verificado e limpo ao passar limpadores de registro, que quase sempre varrem a chave “HKEY_CURRENT_USER Software”, em busca de programas que não existem mais. Já no caso dos arquivos, desconheço uma forma de limpá-los, a menos que se crie um limpador e o programa oriente a cada usuário fazer a limpeza. Mas isso seria praticamente insignificante, pois os arquivos de configuração seriam pequenos e únicos para cada usuário, além do que não é comum um computador doméstico ter muitas contas de usuário. Isso é claro, vale apenas para os usuários que chegaram a abrir o programa, pelo menos uma vez. O futuro deste programa Sonhar nunca é demais, não é? Eis algumas coisas que eu gostaria de implementar ou ver no programa, e trabalho em cima disso ao longo dos tempos sempre que posso, para trazer cada vez mais benefícios aos usuários dele: Auto-correção e verificação ortográfica. O componente SynEdit inclui um item para substituição automática de textos ao digitar, atualmente não usado neste programa, mas sinto falta de um corretor propriamente dito, que destaque as palavras, tenha um dicionário, etc. Ambiente MDI com apenas o campo de edição no formulário do editor. Atualmente o formulário do editor carrega uma instância completa dos menus, componentes visuais, etc. da interface. O ideal seria que os menus, abas e etc. ficassem no formulário “pai”, sendo “fixos”, como ocorre na maioria dos programas MDI. Eu não apliquei isso pois muita coisa precisaria ser alterada. Ao portar a versão 3 do Mep Texto para a 5, basicamente transferi o “frmMepTexto” de formulário principal para secundário e do tipo “MDIChild”, criando um novo vazio (o “pai”) e deixando ele como principal. Manter apenas o editor e uns poucos componentes diretamente relacionados a ele no formulário do editor, economizaria diversos KBytes de memória, otimizando bastante o desempenho quando muitas abas estivessem abertas. Mas mesmo assim, por ser um programa leve, isso não atrapalha tanto. No entanto, estar com 3 abas abertas é diferente de estar com 3 janelas, é claro que da forma que está ele já consome menos memória. Só explicando aqui, pulei a versão 4, que foi fracassada, usando um componente de skins meio problemático. Ela também era SDI, como a 3, e não MDI (não permitia abrir vários arquivos na mesma janela). Melhor suporte a unicode. Não tenho experiência com isso em termos de programação no Delphi, mas gostaria de colocar algo para escolher entre unicode e ASCII ao salvar. Alguns poucos problemas ocorrem, mas ainda bem que o SynEdit normalmente abre e lê corretamente arquivos gerados por programas no Linux – melhor que o Bloco de notas do Windows, para isso, onde normalmente ou funciona os acentos e os textos ficam grudados, sem quebras de linha, ou fica o contrário. Suporte multilíngue! Pensei em aplicar uma vez mas novamente, devido o tempo e trabalho que isso me tomaria, deixei para depois. Não é por “preguiça”, mas daria muito trabalho mesmo, e para fazer um negócio às pressas ou mal feito, simplesmente prefiro não fazer :)* E portá-lo para o Linux, senão diretamente, pelo menos tendo participação no desenvolvimento. Não é que eu divulgue ou faça propaganda do Mep Texto demais, é que ele é considerado por quem testa, realmente superior a editores como o KEdit ou GEdit. Ele perde no quesito corretor ortográfico, por exemplo, e na quantidade de linguagens suportadas na coloração de sintaxe, mas nas outras áreas se mostra muito mais prático e agradável. Quanto à quantidade de linguagens suportadas na coloração de sintaxe, é questão de tempo também, o SynEdit vem com vários componentes prontos, eu não apliquei para linguagens menos usadas para não deixar o editor mais pesado, e não tive reclamações de usuários querendo essas outras linguagens até o momento… Boa sorte! E não se esqueça de me enviar as modificações se você fizer algo significante ou simplesmente interessante 🙂 Créditos ao Julio Cesar Bessa
  3. Parte 2! Indice: Parte 1: Clique aqui Parte 2: Clique aqui Parte 3: Clique aqui Revendo conceitos básicos do IDE Borland Delphi Vamos agora a algumas noções gerais do ambiente Delphi, antes de partir para a modificação do Mep Texto em si. Dicas: Tecle F9 para compilar e executar o programa em desenvolvimento, dentro da IDE do Delphi (para “debugar”), e CTRL + F9 para compilar apenas, além de “Run > Build” para gerar a versão release, otimizada para distribuição. No Delphi, basicamente cada tela de um programa é chamada de “Formulário”, “Form”, em inglês. Não pense que você encontrará campos como nome, idade, telefone, para preencher… Dentro dos formulários você pode colocar os componentes desejados: Para isso observe as abas logo abaixo dos menus e botões do Delphi (Standard, Additional, Win32, System, etc). É a paleta de componentes. Basta clicar em um componente da categoria desejada e então clicar no formulário para inseri-lo. Ao instalar mais componentes, normalmente aparecem outras abas, no final (use a rolagem). Os componentes quase sempre possuem propriedades que podem ser alteradas, tanto em tempo de desenvolvimento (durante a programação, em “compile-time”) como em tempo de execução (quando o programa é executado pelo usuário final, em “run-time”). Para alterar as propriedades durante o desenvolvimento, clique uma vez no componente, e a listagem na tabelinha à esquerda da tela do Delphi será alterada, exibindo as propriedades dele. Essa tabelinha é o “Inspetor de objetos” (“Object inspector”). Ela possui duas abas, “Properties” e “Events” (respectivamente, “Propriedades” e “Eventos”). Ao selecionar um formulário, por exemplo, você pode definir o título da janela, a posição, o tamanho, etc. Ao selecionar um campo de texto, você pode definir o texto que virá dentro dele, a cor, etc. Além disso, é fácil mover ou redimensionar componentes visuais, bastando usar o mouse. Existem também alguns componentes não visuais. Eles executam alguma coisa normalmente sem mostrar nada na tela. Por exemplo, um temporizador (“Timer”). Ele fica de tempos em tempos executando uma mesma coisa (um tempo determinado, através de uma propriedade dele, a “Interval”), o que pode ser somando valores, verificando se o cursor do mouse está numa determinada seção da tela, etc. Ele não exibe nada para o usuário final. Normalmente componentes assim apresentam apenas um quadradinho com um ícone, quando inseridos dentro do formulário, em tempo de desenvolvimento. A posição deles na tela, nestes casos, é insignificante. Os formulários são as telas do programa, e cada formulário é ligado diretamente a uma “Unit”, uma “Unidade de código”. Os arquivos de formulário têm a extensão “.dfm”, e as Units, “.pas” (as units compiladas, “.dcu”, que são os resultados do código-fonte, que o Delphi entenderá e aplicará no programa final). O projeto de um programa normalmente contém vários arquivos, por isso, na hora de fazer backup, copie a pasta inteira, e não apenas o arquivo “.dpr”. Assim sendo, é bom manter uma pasta separada para cada programa que você criar também. Veja uma tela de código, apresentando a Unit1 de um programa teste: Dica: todo formulário no Delphi é associado a uma unidade de código. Quando você estiver na unidade de código, tecle F12 para ver o formulário, e nele, tecle F12 novamente para alternar para o código. Existem, no entanto, unidades de código que não correspondem a nenhum formulário, e são criadas normalmente para agrupar funções semelhantes, dividindo o programa em partes menores – tornando-o mais fácil de ser entendido e editado. O Delphi trabalha com eventos. Os programas para Windows, basicamente, seguem em geral esta idéia: o usuário abre o programa, ele é carregado e então não faz nada, fica esperando a ação do usuário. A pessoa clica em alguma coisa e aí sim algo acontece, como por exemplo, uma mensagem é exibida, um arquivo é aberto, etc. Para definir as ações, os eventos dos componentes sensíveis ao “toque” do usuário final, e mesmo os que podem funcionar sem intervenção do usuário, você deve usar a aba “Events” do inspetor de objetos. Selecione um objeto, vá para essa aba de eventos, escolha o evento desejado (onClick, “ao clicar”, onClose, “ao fechar”, etc) e dê um duplo clique no campo ao lado do nome do evento. Aí a janela de código será aberta, para edição do código. Essa é a parte mais “difícil” para quem está começando, pois é preciso ter mínimas noções de lógica de programação (se bem que eu nunca uso explicitamente…) e claro, conhecer os comandos da linguagem em uso. Se você é iniciante em programação ou gostou deste texto como ponto de partida, sugiro procurar apostilas ou livros sobre Delphi, na Internet mesmo você pode encontrar muitos materiais úteis. Sem noções da linguagem e dos seus comandos, você vai ficar restrito a ver o que o programa tem e modificar as coisas que já estão feitas, alterando posições, textos, etc. Seria a mesma coisa de estar num prompt de comando de um sistema operacional totalmente desconhecido, sem saber o que digitar para fazer alguma coisa, e ele lá, parado, olhado para sua cara 😉 O projeto do programa no Delphi é um arquivo de extensão “.dpr”. Ele sozinho normalmente é pequeno, mas é ele que contém as indicações dos formulários e outras unidades de código que o programa usa. Para abrir um projeto no Delphi, deve-se abrir o arquivo “.dpr” correspondente. Ao compilá-lo, será gerado o programa final. O arquivo final poderá ser um programa (“.exe”), uma DLL (“.dll”), uma proteção de tela, módulo do painel de controle do Windows, etc – dependerá unicamente de como o projeto foi criado, e da sua finalidade. Nem precisa falar que os mais usados são os executáveis e as DLLs! No caso do Mep Texto, como é um programa pequeno, ele não usa nenhuma DLL própria, embutindo no arquivo executável todas as funções, recursos e componentes que necessita para ser executado. Alguns arquivos deverão estar na mesma pasta dele no sistema do usuário, mas estes arquivos poderão ser modificados sem precisar mexer com programação, pois são ícones, arquivos de texto (como a licença de uso), etc. Abrindo e analisando o projeto do Mep Texto Ao abrir um programa criado por uma outra pessoa para modificação, você pode literalmente ficar louco. Especialmente quando você não participou do desenvolvimento desde o começo, não tem contato com o autor, etc., o que normalmente ocorre ao baixar programas open source. Para complicar ainda mais, o código fonte quase nunca é documentado, e o Mep Texto não é exceção. Em programas pequenininhos, muitas vezes com uma única tela de código, você pega toda a lógica e o esquema do programa com uma só olhada. Agora, em projetos maiores… O Mep Texto não é um programa “grande”, mas o código fonte da Unit principal dele, jogado para texto em Courier New tamanho 10, deu 78 páginas em papel A4. Aí dá para você ter uma idéia do que pode vir pela frente… Isso que foi o código do editor apenas, não das outras telas e funções, muito menos os componentes. Como produtor único dele até o dia em que liberei o código fonte, comentarei agora algumas particularidades do projeto, para facilitar para outros programadores que queiram editá-lo. Claro que não comentarei tudo, cada linha de código, isso seria simplesmente impossível. Adianto que você não aprenderá muito sobre o programa lendo o código na ordem em que ele aparece no editor de código. Ele é formado por diversos blocos ou seções, normalmente, você deve verificar nos eventos do objeto selecionado o que você quer modificar. Mas uma coisa que eu gosto de fazer, quando tenho tempo e papel, é imprimir o código fonte, e lê-lo com calma. Às vezes assim eu contro coisas que podem ser modificadas, novas idéias e melhorias surgem, detecto problemas que no computador eu não encontrava, etc. Mas isso não é essencial, cada um é cada um… Com todos os componentes necessários instalados, abra o arquivo “MepTexto.dpr”, da pasta do código fonte, no Delphi. Ele mostrará uma janela com o título “Mep Texto Open”, aparentemente, sem nada dentro. Esta é a tela inicial, a primeira ser carregada quando o programa é iniciado. O Mep Texto 5.0 ou superior é MDI, “Multiple Document Interface”, ele permite abrir vários arquivos dentro da mesma janela (atualmente existem botões para alternar entre eles, mas a idéia é aplicar abas, no futuro). Por isso essa janela inicial é tão vazia, ela não é a janela do editor em si. Ela servirá de base para agrupar as outras janelas. O usuário final do programa nem perceberá isso, pois logo ao abri-lo, ele já cria e carrega uma instância do formulário do editor. Então, o formulário inicial é o “pai”, que é uma janela do tipo “MDIForm”. Ele é o primeiro a ser aberto, pois está definido como formulário padrão: Ele não tem nada visualmente, como falei, mas no código é ele quem possui a chamada para a função de abrir arquivos e novas abas, pois isso pode ser chamado tanto do formulário do editor como antes do editor estar aberto (por exemplo, ao abrir um arquivo com o duplo clique, pelo Windows Explorer). Dica: Clicando no botão “View form” do Delphi (SHIFT + F12) você pode ver os outros formulários; tecle F12 simplesmente para alternar entre o formulário e o código relacionado a ele. O “frmMepTexto” é o formulário que contém o editor em si, e é do tipo “MDIChild” (ou seja, poderão ser abertas diversas instâncias dele dentro do formulário pai). Ele é o que tem mais componentes visuais e também cuja unit (unidade de código) é a que possui o maior código :p Não estranhe, “Tonight” é o codename da versão 5. Para editar os menus você deve dar um duplo clique sobre eles, devido particularidades do componente; idem para as barras de ferramentas (é diferente dos menus padrões do Windows). Ao dar um duplo clique sobre a faixa que contém os menus “Arquivo, Editar, Exibir, etc…” será aberta esta tela: Ela permite editar os itens, adicionar novos, etc. Para editar o código de ação de um item de menu (aquilo que será realizado quando o usuário clicar no menu), abra a tela de edição do menu desejado, selecione o item e dê um duplo clique nele. Ou, com ele selecionado, dê um duplo clique no evento “onClick”, da aba “Events” do “Object Inspector” (aquela tabelinha de duas colunas que fica à esquerda do Delphi; na imagem de tela, está logo acima do botão “Iniciar” do Windows). Você verá que este componente é muito prático e eficiente, e se você não conhecia ainda o ToolBar2000, muito provavelmente gostará tanto que passará a usá-lo nos seus outros projetos. As barras de ferramentas seguem o mesmo estilo, na verdade, qualquer uma pode ser tanto de menus como de ferramentas com esse componente, bastando ajustar algumas propriedades delas, como a exibição dos títulos, imagens, etc. Os menus pop-up são os que contém uma setinha do cursor de mouse com um “+” vermelhinho, no canto inferior direito; ao dar um duplo clique sobre eles, abre-se a mesma tela de edição de menus também. Através do editor dos menus você pode alterar os atalhos de teclado, também. Basta selecionar o item do menu, e alterar a propriedade “Shortcut” dele, pelo Object Inspector. O Mep Texto possui diversos atalhos, muitos comuns em vários programas, e ainda faz uso intensivo das teclas de funções: F1 = Ajuda: sem texto, no momento; Nas versões anteriores tinha, mas adicionei muitas coisas, mudei muitas outras, e ainda não deu tempo de escrever um manual de ajuda completo como eu gostaria 🙂 F2 = Visualizar no navegador: salva o texto atual num arquivo temporário, e abre no navegador (supondo tratar-se de HTML). Se for uma página “.htm” ou “.html’ que estiver sendo editada, então ele abre o arquivo diretamente, sem salvar nos temporários, para manter as referências a possíveis imagens ou links relativos. Alt + F2 = Visualizar no navegador, com quebras de linha. Basicamente copia o texto do editor para um campo temporário, adiciona “<br>” a cada quebra de linha, salva num arquivo temporário e a seguir, abre no navegador. É útil para verificar postagens em blogs, eu uso muito isso, antes de copiar e colar no gerenciador do blog. Assim você digita o texto dando [enter]a cada linha, mas para visualizar num navegador, tecla Alt + F2, para que as quebras sejam aplicadas em HTML. CTRL + F2 = Adiciona o conteúdo do arquivo “HTML.mep”, da pasta do editor, dentro do arquivo atual. Este serve como um modelo, criado pensando-se em quem mexe com HTML, mas o conteúdo do arquivo pode ser personalizado para qualquer coisa. F3 = Tradicional “Localizar próxima”, para pesquisar textos. F4 = Insere a tag “<br>”, do HTML. Só tem utilidade para quem mexe com HTML. F5 = Copiar (além do CTRL + C, claro) F6 = Colar F7 = Recortar F8 = Copiar tudo (seleciona tudo e já copia para a área de transferência do sistema) F9 = Tela de inserção de textos rápidos (será comentada nos recursos especiais do Mep Texto, logo mais) F10 = Não aplicada a nada, por enquanto :p F11 = Abrir arquivo F12 = Salvar arquivo (salvar comum, é mais cômodo teclar F12 do que CTRL + S ao salvar continuamente um texto que não se quer perder) SHIFT + F12 = Salvar como CTRL + F12 = Salvar e fechar (ideal para quando você termina de editar um arquivo, já salva e fecha direto). Como medida de precaução, ele verifica antes de fechar se o arquivo foi realmente salvo. Boa parte dos atalhos citados acima não estão nos menus, eles ficam “ocultos”. Há um menu “Oculto”, que usei para poder aplicar estes atalhos, ele na verdade redireciona os eventos dos seus itens (também ocultos) para os itens correspondentes dos outros menus. Isso permite que também sejam aplicados os tradicionais, como CTRL + A, CTRL + T, etc, sendo estes tradicionais os exibidos ao usuário. Esse menu oculto pode ser visto no editor dos menus, ele fica após o “Infodoido”, e este depois do “Ajuda”. Nota: o menu “Infodoido” criei e deixei oculto por padrão, inicialmente para aplicar testes de novos recursos. Marcando a opção “Ativar na interface visual opções avançadas ou adicionais, algumas em beta”, na tela “Outras configurações” das opções, esse menu aparece para o usuário final. Atualmente contém dois itens apenas, um que converte o texto do editor substituindo algumas letras por números, g3r4nd0 73×705 4551m, e outro que reconverte estes textos doidos em textos normais, substituindo os números pelas letras. Ainda sobre os menus, eu apliquei um efeito agradável para muita gente, que lembra bem – mas é diferente – os menus do Office 2000 ou o “Iniciar > Programas”, do Windows Me/2000 ou superiores. Eles exibem apenas as opções mais comuns ou mais usadas, mas no Mep Texto elas são fixas e definidas durante o projeto do programa. No final dos menus há uma setinha, para expandi-los e assim exibir os outros itens: Os componentes usados não fornecem um meio de gerenciar esse tipo de menu, eu usei um artifício: deixando os itens desejados ocultos, e alterando a propriedade “Visible” deles para True quando o usuário passar o mouse sobre o item que contém a setinha, tem-se o efeito desejado. O item que contém a setinha é um item de menu normal, apenas com as propriedades devidamente configuradas para ficar sem texto, e com a imagem da setinha alinhada ao meio. Da mesma forma, como os menus podem ser abertos a qualquer momento, ao clicar nos menus (Arquivo, Editar, etc.) a propriedade “Visible” dos itens desejados é mudada para False. Isso na verdade com uma mesma função (a “AplicaMenusReduzidos”), que recebe como parâmetro um valor booleano, decidindo se ocultará ou não os itens dos menus. Isso é controlado pela variável global no editor, “menusRed”, que é inicializada ao carregar as opções. O usuário pode desativar esse recurso nas opções, fazendo com que os menus sempre apareçam completos. Para localizar no código, procure os eventos “Arquivo1Popup”, que é comum a todos os menus, e “maisArquivoSelect”, que é comum aos últimos itens da maioria dos menus, que são justamente os itens que contém a setinha. Digo da maioria dos menus, pois menus que possuem poucos itens não precisam disso (como o “Ajuda”), já exibindo todos os itens diretamente. Dentro do formulário do editor, alguns eventos importantes são o onCreate e o onClose, do formulário “frmMepTexto”. Selecionando o “frmMepTexto” na listinha do topo do Object Inspector, e então clicando na aba “Events”, você poderá acessá-los facilmente. O evento onCreate do formulário do editor é muito importante. Ele é chamado sempre que o editor é criado, ou seja, quando o programa é aberto, ou quando uma nova aba é aberta. As principais funções chamadas por ele são: VerificaConfiguracoes – Carrega as opções do registro, alterando em tempo de execução, diversas opções do editor. Esta função é pública, pois será chamada também pela tela das opções. Quando o usuário clicar em “Aplicar” na tela das opções, as mesmas serão gravadas no registro, e esta função será chamada do editor, para recarregar as novas opções. CarregaFonte – Verifica e aplica o tipo de letra do editor, cor e tamanho. CarregaMensagens – Esta carregaria os textos da interface, baseando-se numa escolha feita pelo usuário. Este recurso não está implementado, eu coloquei pensando em torná-lo multilíngue, mas isso me tomaria um tempo impraticável, dado o avanço do programa, a quantidade de coisas a mexer e alterar, etc. No entanto, ela é chamada pois define alguns textos, mesmo em português, para alguns itens de menus e da interface. No evento onClose ele verifica se existe apenas uma aba aberta. Se existir, ele fecha o programa inteiro, supondo que o usuário tenha fechado o programa, ou que seja a última aba a ser fechada. Caso contrário, ele fecha apenas a aba atual liberando a memória dela, mas deixando a aplicação aberta, devido às outras abas. Isso será chamado, por exemplo, quando o usuário clicar no X da janela para fechá-la, ou ao escolher a opção “Sair e fechar tudo” no menu “Arquivo”. Além desse onClose, logo abaixo dele há um item muito importante num editor, que lida com arquivos do usuário. Trata-se do evento onCloseQuery. Ele é chamado sempre que o usuário tentar fechar a tela do programa, mas pode impedir o fechamento, se for o caso (devolvendo a variável CanClose como True, então pode fechar; caso contrário, não pode). Aqui coloquei uma chamada à função de nome “ChecaArquivoSalvo”, que traz um resultado de um tipo definido por mim no programa, que pode ser “mSalvar”, “mNaoFechar”, ou “mDescartar”. Ela justamente verifica se o arquivo está salvo ou não, vendo a propriedade “modified” do editor, além do nome do arquivo. A tela exibida perguntando se o usuário quer salvar o arquivo ou não, é um formulário a parte, “frmSalvar”: Muitos programas para Windows usam nessa hora uma janela de mensagem padrão (normalmente da própria API do Windows), como esta, por exemplo: No Mep Texto as mensagens e a janela são personalizadas, trazendo uma interface mais didática e agradável ao usuário final, além de possuir um link “Mostrar dicas de salvamento”. Esta mesma tela, chamada pela mesma função ” ChecaArquivoSalvo”, será exibida caso o usuário esteja com um arquivo aberto e tente criar um novo, sem salvar o atual, por exemplo. O código para ela é o mesmo e único, eis uma das vantagens da programação orientada a objetos: o reaproveitamento de código, tendo um programa mais “limpo”. Dependendo do resultado que ela retornar (que obviamente, dependerá do botão em que o usuário clicar), o programa executará uma ação aí sim, variável conforme de onde foi chamada. Por exemplo, ao fechar um arquivo não salvo, se o usuário pedir para não salvar, o editor será fechado. Mas ao criar um novo arquivo, se o usuário não quiser salvar o atual, o editor não será fechado, mas sim o novo arquivo será criado. Isso chamado por lugares diferentes, no caso o meu “Arquivo > Novo” e o evento “onCloseQuery” do formulário, mas usando uma só função de verificação, a “ChecaArquivoSalvo”. Normalmente os nomes das funções estão em português, afinal o Mep Texto foi desenvolvido do zero por mim, sem ser baseado em nenhum outro programa. Porém, funções aproveitadas de outros códigos ou programas, ou as que respondem a eventos gerados automaticamente pelo Delphi, estarão em inglês, como “item1click”, “btn2dblclick”, etc. O “FormConfigurar” é a tela das opções, o código também é grandinho, mas não se compara ao do editor: Se você curiar nas outras abas em tempo de desenvolvimento, não se esqueça de voltar para a primeira antes de fechar e compilar o projeto, senão a última guia exibida ficará como padrão e será apresentada aberta para o usuário final. Quando você adicionar ou remover opções, é bom alterar as funções “AplicaConf” e “CarregaConfig” do “FormConfigurar”. Elas são carregadas pelo editor com a “VerificaConfiguracoes”, já comentada, na unidade de código do “frmMepTexto”. Elas são chamadas, respectivamente, pelo evento “onClick” do botão “Aplicar” e pelo “onCreate” do “FormConfigurar”. É bom também colocar um item para redefinir (remarcar um checkbox, por exemplo) as suas novas opções padrões, quando o usuário clicar no “Restaurar para a configuração padrão…”. As opções são gravadas no registro, sob a chave “HKEY_CURRENT_USER Software Mep Mep Texto”. Se você quiser mudar esse caminho, use o recurso do menu “Search > Find in files” do Delphi e substitua as ocorrências de “SoftwareMepMep Texto” pelo que quiser. Como são muito usadas, eu criei duas funções para escrita e leitura no registro, e inclusive as utilizo em outros programas também, simplificando bastante o trabalho do programador (em vez de criar uma variável de registro, abrir a chave, o valor, editar o valor, fechar a chave e destruir a variável todas as vezes, repetindo isso para cada opção, basta chamar estas funções, dizendo que chave será modificada, o valor a ser gravado, o tipo dele, etc). Estas (e outras) funções estão na unit “MepUtil2.pas”. A sintaxe da função que lê os dados do registro é esta: function LeReg(mepRoot: Cardinal; Chave: String; const Key: String; KeyType: TKeyType; DefValue: Variant): Variant; Exports LeReg; Estes são os parâmetros (estou comentando pois certamente você precisará desta função, caso adicione ou remova configurações que possam ser personalizadas pelo usuário): mepRoot: a chave root. Use HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, etc. Chave: a chave em si. No caso, usei uma espécie de constante, chamei-a de minhaChave, para não ficar digitando toda hora. Por exemplo, use SoftwareSeuNomeSeuPrograma. Key: o valor a ser lido, dentro da chave fornecida no parâmetro anterior. KeyType: o tipo de dado. Os valores possíveis estão definidos na “MepUtil2.pas”, e são: ktString (para textos), ktBoolean (para valores booleanos, verdadeiro ou falso), ktInteger (para números inteiros), ktCurrency (valores monetários), ktDate (datas), e ktTime (horas). Dispensam maiores comentários. DefValue: o valor padrão que a função retornará se o valor não existir no sistema do usuário (por exemplo, na primeira abertura do programa). A que grava dados no registro, é a EscreveReg, cuja sintaxe é esta: procedure EscreveReg(mepRoot: Cardinal; Chave: String; const Key: String; const Value: Variant; KeyType: TKeyType); Exports EscreveReg; É similar à anterior, e agora também dispensa comentários. Note apenas o parâmetro “Value”, que contém o valor a ser gravado, ele é do tipo Variant, e será gravado no registro usando o tipo definido em KeyType. Estas funções se tornam um importante aliado na praticidade para gravar e ler dados em qualquer chave do registro, mesmo que não seja para este projeto. Estas funções podem ser usadas em qualquer tela do Mep Texto, se o formulário não possuir, basta adicionar a unit “MepUtil2.pas” na cláusula “Uses” da unidade do formulário que você quiser. A maioria das telas dele já incluem essa referência. Comentado agora rapidamente as outras telas… Relacionada às opções, temos o “frmMRU”, um agrupamento para personalização da lista de arquivos recentes: Ela é chamada ao clicar no “link” “Alterar as opções da lista dos últimos arquivos abertos”, na tela das opções principais. O código de gravação das opções é feita pelo código do evento “onClick” desse link, na unit de código do “FormConfigurar”, e não por esse formulário pequeno, “frmMRU”. A tela da impressão (“frmImpressao”) é uma mera interface, basicamente todo o trabalho de impressão é comandado pelo componente SynEdit, do editor: No mesmo estilo visual dela (tamanho e faixas superiores) há o “FormPrivacidade”, que permite, com um clique, limpar os dados pessoais do usuário, ideal para ser usado em computadores públicos: Sim, essa idéia retirei do Mozilla Firefox 🙂 Inclusive vai o atalho “Ctrl + Shift + Del”, ou pelo menu “Configurar > Limpar dados pessoais”. A limpeza limpa a lista de arquivos recentes, a pasta do Backup Paranóia (você conhecerá ela logo, logo, mais a frente, neste texto), e inclusive a pasta temporária do Mep Texto dentro da pasta “Temp” do perfil do usuário no Windows. Essa pasta é usada para salvar as páginas HTML quando usado o recurso “Visualizar no navegador”, mas os arquivos não são removidos automaticamente, daí a inclusão desse item nesta tela de limpeza. Se você pretende usar arquivos temporários, com dados de arquivos do usuário, essa pasta é um bom lugar para armazená-los (a pasta “Temp Mep Texto”, dentro da pasta “Temp” do perfil do usuário atual). Temos ainda o “FormLicenca”, que exibe a tela de licença, puxando o texto do arquivo “license.txt” (que deve estar na mesma pasta do programa): Esta tela de licença é exibida na primeira execução do programa para cada usuário do computador. Ao clicar em “Aceitar”, será gravado o valor “Lic” com o valor 1, na chave de registro do programa (HKEY_CURRENT_USER Software Mep Mep Texto), e então esta tela não mais será exibida automaticamente na inicialização. Ela também será exibida ao clicar no item “Licença de uso” do menu Ajuda, mas aqui, sem os botões “Aceitar” e “Recusar”, basicamente modificando em tempo de execução a posição e o texto deles (veja como isso é feito no evento “onClick” do menu “Ajuda > Licença de uso”). Ainda seguindo o mesmo estilo estético de janelas (tamanho, logo e faixa superiores), temos o “FormSubstLote”, que permite substituir ocorrências de texto em lote (tive problemas ao usar isso com alguns arquivos Unicode, funcionando perfeitamente em arquivos ASCII): Devido a esse recurso (que pode ser acessado pelo menu “Pesquisar > Substituir texto em lote”), incluí também uma tela de progresso, o “frmProgresso”: Apesar destes formulários, todo o mecanismo de substituição e atualização da tela de progresso ficam por conta do código inserido na unit “frmMepTexto”, no evento “onClick” do item de menu “Pesquisar > Substituir texto em lote…”. O Mep Texto inclui também um visualizador das fontes instaladas no Windows, apesar de ser um editor de textos puro e se dar melhor com fontes mono-espaçadas. Ele pode ser chamado pelo menu “Exibir > Visualizar fontes instaladas”: Finalizando, temos a tela “Sobre”, formada por algumas guias (“abas”), no “Form7_Sobre”. Essa idéia me veio do KDE, da tela “sobre” dele, utilizada em vários programas para Linux: Ela exibe informações sobre o uso de memória, versão de Windows, e inclui o componente de HTML integrado do IE (o quadro branco, na imagem acima) onde é carregada uma página HTML. Estas imagens de tela são das telas em tempo de desenvolvimento. No lugar dos quadros com pontilhados, ficarão imagens reais 🙂 Um bom exemplo disso são as telas que têm o mesmo tamanho e aparência no Mep Texto (como a de substituição de texto em lote, impressão, limpeza de dados pessoais, etc). Ele carrega estas imagens em tempo de execução, puxadas de um arquivo de recurso (o “mt.res”). Esse arquivo pode ser editado (para trocar as imagens) com editores de recursos, como o Resource Hacker, ou com editores inclusos em alguns ambientes de programação. Nada impede, no entanto, que você coloque outras imagens diretamente. Apliquei como “resources” devido o compartilhamento, elas são usadas em várias telas, e assim são armazenadas uma única vez no arquivo. Na verdade, em tempo de execução, as imagens serão puxadas do próprio executável do programa. Elas estão armazenadas neste arquivo para serem facilmente substituídas durante o desenvolvimento, mas este arquivo será embutido no executável durante a compilação. Créditos ao Julio Cesar Bessa
  4. Parte 1! Indice: Parte 1: Clique aqui Parte 2: Clique aqui Parte 3: Clique aqui Introdução O Mep Texto é um editor de textos puro para Windows, que comecei a desenvolver (em Delphi) no final de 2004. A idéia era – e é! – ser um editor de textos puro, sem formatação, o famoso “.txt”, mas que deixe o Bloco de notas comendo poeira. Aos poucos ele foi evoluindo, com a inclusão de novos recursos e componentes: coloração de sintaxe para diversas linguagens, backup paranóico, inserção prática de textos e frases muito usados pelo usuário, temas visuais… Um programa essencial para muitos, não tão conhecido, é claro, mas quem vê normalmente gosta. Enquanto escrevo ele está na versão 5.0 beta 3 (junho de 2007), mas havia uma questão: era freeware, mas de código-fonte fechado. Fiquei surpreso e feliz ao vê-lo rodar no Linux, usando o Wine, praticamente sem grandes problemas. Agora pode ser usado no lugar do KEdit ou GEdit, para mim e para quem quiser, é claro. Isso devido às facilidades, atalhos e recursos. Então dei vida a uma idéia um pouco antiga mas que eu ficava com um pé atrás: liberar o código fonte! Assim sendo, tem agora o Mep Texto Open, licenciado sob a GPL v.2. Numerei-o como a versão 1.0 Open, baseado no Mep Texto 5. Continuarei paralelamente com o projeto de código fechado, pelo menos por um tempo, inclusive devido o uso de skins e componentes de terceiros, que são fechados. Mas o Open está aí, pronto para ser personalizado, melhorado, quem sabe até traduzido e/ou portado para o Linux (coisa que não tenho condições hoje de fazer sozinho). Todos têm a ganhar com a abertura, então para quem programa em Delphi (ou Kylix, ou tem noções de Pascal…) escrevi este artigo, dando orientações de como personalizá-lo. Veja a cara da versão Open: Comecei ele em Delphi 4, depois passei para o 7, e a volta é praticamente irreversível. Compilo hoje sob o Delphi 7, não testei nas versões superiores, então não posso garantir nada. Tanto em versões mais novas como mais antigas do Delphi, a maior dificuldade pode ser com a falta de suporte dos componentes, e não com o código do programa em si. Ingredientes, para poder modificá-lo: Ter o Borland Delphi 7 instalado, é claro! Ter noções de Delphi ou outra linguagem de programação, este texto não é para iniciantes nem para usuários finais 🙂 Todavia não desanime, fuçar no código fonte de programas é um ótimo meio de aprendizagem! Estarei abordando de forma a deixar pronto para qualquer um sair modificando, mesmo que nunca tenha mexido com programação antes; sugiro, no entanto, estudar alguma coisa da linguagem Pascal / Delphi, senão você terá grandes barreiras e dificuldades, por desconhecer a sintaxe e funções básicas da linguagem. Instalar os componentes para Delphi fornecidos com o pacote do código fonte. Você pode baixar tanto o programa pronto (para usuários finais) como o código-fonte e os componentes usados, em: http://www.mephost.com/software/meptexto Componentes necessários Se você não sabe, os componentes são recursos que podem ser inclusos nos programas. Eles sozinhos não servem para nada, não passam de um monte de código. Os programas implementam o uso dos componentes e fazem chamadas às funções e recursos dos mesmos, para que eles se tornem úteis. Na programação orientada a objetos, que vem a ser o caso do Delphi (e de muuuitos outros ambientes de programação, quase todos hoje 😉 os objetos são, numa definição para leigos, “coisas”, literalmente “objetos” que podem ser reaproveitados em outras partes do programa, ou em outros programas. O Delphi traz diversos componentes com ele (especialmente os da VCL, “Visual Component Library”, “Biblioteca de Componentes Visuais”), mas nunca uma coisa feita e finalizada uma vez é “completa”, em se tratando de linguagem de programação. Existe a possibilidade de se criar componentes personalizados (não que isso seja fácil, rs), e instalá-los no Delphi, para uso dos programas, adicionando recursos que não vinham com o Delphi, pois em programação pode-se fazer praticamente de tudo! (menos café, como diz meu pai, rs). Basicamente o Mep Texto usa alguns componentes que não vêm com o Delphi, portanto, para modificar o programa, você deverá instalá-los. Todos os componentes usados no Mep Texto Open são abertos, não necessariamente GPL, mas incluem o código fonte. Alguns componentes requerem que determinados arquivos sejam distribuídos junto com o programa para poderem funcionar, normalmente na forma de arquivos OCX ou DLL (também chamados de “Controle Active-X”, um componente pronto que pode ser usado por outros programas em tempo de execução; por isso que muitos programas requerem determinadas bibliotecas instaladas, como as do Visual Basic, do .NET Framework, etc). Uma coisa que o Delphi tem de bom é que ele embute no executável tudo o que ele precisa (a menos que você não queira). Então você deve instalar os componentes apenas durante o desenvolvimento do programa, sem se preocupar com os usuários finais. Depois de pronto, o programa rodará em qualquer versão de Windows suportada, sem precisar de arquivos adicionais. Forneci os componentes junto com o código fonte por questões práticas, assim tem-se num único pacote tudo o que você precisa, com as mesmas versões testadas e aplicadas por mim. Já baixei programas abertos sem que eu pudesse encontrar os componentes usados, seja porque o autor só liberava as novas versões ou porque o site saiu do ar, então sei bem como é complicado ter um projeto em mãos e não encontrar as dependências de que ele necessita. Para começar, descompacte o arquivo com o código fonte, e então descompacte os componentes, cada um para uma pasta própria, em uma pasta fixa no seu computador. Eu normalmente crio uma pasta “Comps” dentro da pasta do Delphi, e deixo os componentes em subpastas dentro dela. Digo “pasta fixa” pois, se você mudá-la de lugar depois, deverá atualizar os caminhos das indicações das pastas no Delphi, para que ele possa achar os componentes. Eis os componentes usados no Mep Texto Open: Components – IS3.zip psvDialogs.zip SynEdit-2_0_3.zip tb2k-2.1.5-xp.zip tbx-2_0.zip Se você mexe com o Delphi então já deve saber instalar os componentes, aqui vai apenas um resumo. Mas se será sua primeira experiência, relaxe, não é complicado instalá-los: Components – IS3.zip psvDialogs.zip SynEdit-2_0_3.zip tb2k-2.1.5-xp.zip tbx-2_0.zip Nota: se você tem alguma outra versão de um destes componentes instalada, não é bom se arriscar, a menos que você conheça profundamente cada um deles e já tenha intimidade com o Delphi, para saber como corrigir erros depois. O que eu sugiro neste caso é criar uma nova conta de usuário no seu Windows (supondo que seja o 2000/XP ou superior) e abrir o Delphi por ela, visto que no Delphi 7 os componentes são separados para cada usuário. Se você não sabe do que estou falando, então não se preocupe com isso, pois provavelmente você não terá outras versões desses componentes. Se você não lembra ou nunca instalou componentes, vamos lá. Primeiro, devemos adicionar a pasta da fonte dos arquivos, onde ficarão os arquivos compilados. É semelhante à variável de ambiente “path” dos sistemas operacionais, devemos indicar ao Delphi as pastas onde ele pode encontrar o código-fonte e as “peças” compiladas dos componentes a serem usados. Sem fazer isso, ao tentar compilar um programa que use um determinado componente não localizado, você receberá uma mensagem de erro, e o programa não será compilado. Para alguns componentes a pasta pode ser adicionada no Delphi depois da instalação, mas em outros ele simplesmente não consegue compilar se não achar a pasta, então é bom adicioná-la antes de compilar. Para adicionar as pastas dos arquivos no Delphi, faça isso: clique no menu “Tools > Environment Options…” do Delphi, e vá para a aba “Library”. No primeiro campo dela (“Library path”), clique no botão com as reticências ao lado: E então digite ou cole o caminho de cada pasta no campo do nome, e clique em “Add” (nunca em “Replace”, a menos que esteja substituindo uma versão anterior do mesmo componente!). Veja: Faça isso para cada componente, pode ser adicionando a pasta e compilando ele, depois o outro, etc. Cuidado: inclua a pasta certa, em alguns componentes é a pasta “source” que fica dentro da pasta dele, em outros é a própria pasta dos arquivos do componente; isso varia de componente para componente, pois cada programador faz do seu jeito… Veja a listagem dos componentes usados anteriormente neste texto, para não se confundir. Adicionadas as pastas, é necessário compilar os componentes. O Delphi não gerará “programas” com base no código fonte dos componentes, ele gerará “pedaços” que poderão ser usados depois. Normalmente os arquivos compilados do Delphi têm a extensão “.dcu” (de “Delphi Compiled Unit”, “Unit Compilada do Delphi”). “Unit” neste caso é cada um dos arquivos de extensão “.pas”, que são arquivos de texto com o código fonte, e podem ser editados em praticamente qualquer editor de textos puro. Para compilar… Existem algumas formas diferentes de instalar os componentes no Delphi. Para facilitar, distribuí todos eles com o pacote pronto, o arquivo de extensão “.dpk” (de Delphi Package). Eles devem ser abertos no Delphi (de preferência, na ordem recomendada mais acima, na listagem) e compilados um por um. Para compilá-los, basta clicar em “Compile” e depois em “Install”, na telinha que se abre logo ao carregá-los: Você só precisa fazer isso na primeira vez, depois basta abrir o código do programa em si e mandar ver. Se o Delphi perguntar se você quer salvar o arquivo, fica a seu critério; se você não alterar indevidamente o código dos componentes, não haverá problema nenhum em salvá-los. Após instalar todos os componentes é bom clicar em “File > Close all”, no Delphi, para fechar as janelas dele e deixá-lo livre para abrir o projeto do programa em si. Com os componentes devidamente instalados, basta abrir o “MepTexto.dpr” da pasta do código fonte. Se tudo estiver OK, você já pode sair adicionando ou removendo coisas, personalizando, etc. Créditos ao Julio Cesar Bessa




×