Jump to content

Manimal

Administradores (Adm)
  • Content count

    520
  • Joined

  • Last visited

  • Days Won

    65

Manimal last won the day on January 22

Manimal had the most liked content!

Community Reputation

166 Ótimo

2 Followers

About Manimal

  • Rank
    Membro Avançado
  • Birthday 09/06/1967

Profile Information

  • Gender
    Male
  • Location
    Videira/SC
  1. Criar e ler um banco de dados SQlite

    Buenas! Sempre que falamos em clonar um banco em memória, nosso objetivo é melhorar o tempo de resposta para funções de massa, como grandes e complexas consultas por exemplo, que talvez ao serem efetuadas a partir do disco (BD original) possam resultar bem mais lentas para apresentar os resultados. Grandes alterações no banco como inserção em massa de dados, alterações ou exclusões também podem ocorrer. Então, ao clonarmos o BD para a memória, temos que ter em mente que eventuais alterações feitas na memória podem ter 2 (dois) destinos: são ignoradas, ou seja o BD serve apenas para SELECTs e o que vale é o BD em disco; precisam ser salvas, ou seja, em algum momento, precisam ser descarregadas/efetivadas/replicadas em disco. Na opção 1, o problema está resolvido. Ignora-se o BD em memória e tudo bem! Na opção 2 o buraco é bem mais embaixo. Aqui temos novamente 2 (duas) possibilidades: efetivamos as alterações à medida que acontecem! Pessoalmente é a que eu utilizo por algumas razões: mantenho o BD em memória igual ao BD no disco (sincronização); caso ocorra alguma falha no equipamento (reset, falta de luz, travamento, etc) as alterações estão seguras; ao iniciar o script, carrego novamente o BD em memória, sabendo que é a última versão das informações e parto disto; não preciso me preocupar em descarregar as alterações posteriormente (no final do programa ou em algum ponto definido) e neste momento qualquer ganho de tempo que eu tive, foi por água abaixo, pois o tempo de gravação em disco de todas as alterações é enorme. Como fazemos isso? Após a clonagem do BD em memória, qualquer alteração ao ser executada, deve ser feita tanto em memória como em disco. #include <Sqlite.au3> ; incializa SQLite _SQLite_Startup() ; Abre BD em mmória Local $hBD_Mem = _SQLite_Open() ; Abre BD em disco Local $hBD_Disco = _SQLite_Open(@ScriptDir & "\BancoDeDados.db") ; ... ; Faz a clonagem conforme as técnicas explicadas em post anterior ; ... ; faz as eventuais alterações no BD mem e no BD disco _SQLite_Exec($hBD_Mem, "UPDATE Tabela SET Estado = "SC" WHERE Codigo = 425;") _SQLite_Exec($hBD_Disco, "UPDATE Tabela SET Estado = "SC" WHERE Codigo = 425;") ; faz as eventuais alterações no BD mem e no BD disco _SQLite_Exec($hBD_Mem, "DELETE FROM Tabela WHERE Idade < 18;") _SQLite_Exec($hBD_Disco, "DELETE FROM Tabela WHERE Idade < 18;") ; fecha tudo _SQLite_Close() _SQLite_Shutdown() Desta forma, mantemos os dois bancos de dados iguais e atualizados. E quaisquer consultas (SELECTs) devem ser feitos diretamente no BD em memória para obter um ganho considerável de velocidade! A outra possibilidade envolve não manter os 2 (dois) bancos equiparados ou sincronizados, mas fazer as alterações somente em memória e depois de tudo pronto, descarregar o BD da memória em disco. Este procedimento pode ser feito a qualquer momento, mas normalmente é efetivado na saída do programa (final do script). Para tanto, infelizmente não há um comando ou comandos que possam fazer isto rapidamente. Felizmente a partir da versão 3.6.x do SQLite, foi implemntadado a API de Backup, que permite fazer cópia do banco "on-the-fly" (com o banco aberto e operando). No fórum americano, tem um tópico sobre isto (cortesia do Belini que achou) e também tem uma função para fazer o backup: Se quiser ver o tópico original = https://www.autoitscript.com/forum/topic/108151-sqlite-backup-api-wrapper/ Vou anexar aqui uma versão modificada da original, já contendo as alterações sugeridas pelos integrantes do fórum naquele tópico e com algumas modificações minhas também. Para utilizar a função de Backup é bem simples. Segue exemplo: #include <Sqlite.au3> #include "sqlitebackup.au3" ; incializa SQLite _SQLite_Startup() ; Abre BD em mmória Local $hBD_Mem = _SQLite_Open() ; Abre BD em disco Local $hBD_Disco = _SQLite_Open(@ScriptDir & "\BancoDeDados.db") ; ... ; Faz a clonagem conforme as técnicas explicadas em post anterior ; ... ; faz as eventuais alterações SOMENTE na memória _SQLite_Exec($hBD_Mem, "UPDATE Tabela SET Estado = "SC" WHERE Codigo = 425;") ; faz as eventuais alterações SOMENTE na memória _SQLite_Exec($hBD_Mem, "DELETE FROM Tabela WHERE Idade < 18;") ; faz o backup do BD em memória de volta para o disco (recomendado ao final do script) _SQLite_Backup($hBD_Mem, @ScriptDir & "\BancoDeDadosCOPIA.db") ; fecha tudo _SQLite_Close() _SQLite_Shutdown() Mas conversando com um outro colega (meu ex-orientandor de mestrado) que é DBA, ele me comentou que alguns engines DBs aproveitam comandos de manutenção do banco (que exigem controle total sobre o mesmo) para efetivar algum tipo de cópia. Assim, fui pesquisar na documentação do SQLite e o comando VACUUM, que serve para fazer uma lmpeza interna do banco, a partir da versão 3.27 possui uma cláusula INTO que faz exatamente isto! Agora temos 2 (duas) opções de salvar o banco de dados da memória em disco. Faca os testes e veja qual a melhor (ou a mais rápida) que serve para o seu caso. A vantagem é que não precisa de uma função externa. #include <Sqlite.au3> ; incializa SQLite _SQLite_Startup() ; Abre BD em mmória Local $hBD_Mem = _SQLite_Open() ; Abre BD em disco Local $hBD_Disco = _SQLite_Open(@ScriptDir & "\BancoDeDados.db") ; ... ; Faz a clonagem conforme as técnicas explicadas em post anterior ; ... ; faz as eventuais alterações SOMENTE na memória _SQLite_Exec($hBD_Mem, "UPDATE Tabela SET Estado = "SC" WHERE Codigo = 425;") ; faz as eventuais alterações SOMENTE na memória _SQLite_Exec($hBD_Mem, "DELETE FROM Tabela WHERE Idade < 18;") ; faz o backup do BD em memória de volta para o disco (recomendado ao final do script) aproveitando o comando interno VACUUM _SQLite_Exec($hBD_Mem, "VACUUM INTO '" & @ScriptDir & "\BancoDeDadosCOPIA.db'") ; fecha tudo _SQLite_Close() _SQLite_Shutdown() Quanto à eficiência de gravação de volta em disco, temos que lembrar que estas funções, tanto a do SQLite como a do backup da SQLite, foram desenvolvidas tendo em mente uqe estes bancos estariam abertos, sendo utilizados por mais de 1 (um) usuário, portanto durante o procedimento de fazer a cópia, é possível que haja alterações por parte de outros usuários, sendo assim, a cópia já nasceria desatualizada. A API do Backup prevê isso e se necessário, recomeça a cópia par refletir estas alterações. Porém naturalmente que dependendo da quantidade de usuários conectados ou das alterações que estão sendo feitas, a cópia pode demorar eternamente! Outro ponto interessante a ser verificado é que o 5o (quinto) parâmetro da função de Backup é o tamanho do bloco que deve ser copiado. E por tamanho do bloco, temos que olhar a estrutura interna do banco de dados para entendermos melhor este parâmetro e o porque da fixação dele em 16. Todo banco de dados, internamente, possui as informações gravadas em blocos como se fossem páginas de um livro. Dentro da página tem as várias informações de vários registros. O procedimento de backup faz cópia de "x" folhas por vez (padrão de 16). Assim caso alguma dessas folhas sejam modificadas, ela recopia somente estas folhas que estão no bloco. Em teoria, quanto menor este bloco melhor, pois estaríamos reduzindo a recópia (se necessário), porém ao reduzirmos o tamanho do bloco, também aumentamos o tempo necessário para copiar tudo. Assim, aumentar o tamanho do bloco faz com que a cópia seja mais rápida, mas mais sujeita a recópias. Dependendo da situação, e eu estou imaginando que em 90% (ou mais) dos casos de SQLIte com AutoIt, os bancos são praticamente exclusivos, não tem niguém além do próprio script mexendo e também não há vários scripts rodando simultameamente na rede. Se for este o seu caso, pode aumentar o nro de blocos para 256 para obter uma melhor performance na cópia do banco ou até mesmo colocar o valor de -1, para que seja usada a velocidade máxima. Mas muito cuidado com estes parâmetros. Eles devem ser cuidadosamente considerados em razão do ambiente em que o banco de dados está sendo executado. _SQLite_Backup($hBD_Mem, $sCopiaBD, Default, Default, 256) ou _SQLite_Backup($hBD_Mem, $sCopiaBD, Default, Default, -1) SQLitebackup.au3
  2. Criar e ler um banco de dados SQlite

    Para clonar o banco de dados em memória, tem várias opções. Todas dá no mesmo, mas vc escolhe a melhor. Opção 1 (a mais rápida): #include <Sqlite.au3> ; inicializa SQLite _SQLite_Startup() Local $hBD_Mem = _SQLite_Open() ; importa os dados _SQLite_Exec($hBD_Mem, "ATTACH DATABASE '" & @ScriptDir & "\BancoDeDados.db' as Original;") _SQLite_Exec($hBD_Mem, "CREATE TABLE Dados AS SELECT * FROM Original.Dados;") _SQLite_Exec($hBD_Mem, "DETACH DATABASE Original;") ; fecha tudo _SQLite_Close($hBD_Mem) _SQLite_Shutdown() Opção 2 (a intermediária), precisa saber a estrutura do banco. É útil quando vc precisa mudar a estrutura ou precisa pegar apenas alguns campos: #include <Sqlite.au3> ; inicializa SQLite _SQLite_Startup() Local $hBD_Mem = _SQLite_Open() ; importa os dados _SQLite_Exec($hBD_Mem, "ATTACH DATABASE '" & @ScriptDir & "\BancoDeDados.db' as Original;") _SQLite_Exec($hBD_Mem, "CREATE TABLE IF NOT EXISTS Dados (Numeros TEXT);") _SQLite_Exec($hBD_Mem, "INSERT INTO Dados SELECT * FROM Original.Dados;") _SQLite_Exec($hBD_Mem, "DETACH DATABASE Original;") ; fecha tudo _SQLite_Close($hBD_Mem) _SQLite_Shutdown() Opção 3 (a mais lenta), mas é a que permite mostrar alguma coisa tipo uma barra de progresso. Útil quando a tabela é muito grande. #include <Sqlite.au3> ; inicializa SQLite _SQLite_Startup() Local $hBD_Mem = _SQLite_Open() Local $hBD_Disco = _SQLite_Open(@ScriptDir & "\BancoDeDados.db") If @error Then ConsoleWrite("Erro na abertura do banco de dados" & @CRLF) Exit EndIf ; seção que carrega a tabela em memória (array) Local $aConsulta, $nLinhas, $nColunas SplashTextOn("", "Inicializando banco de dados...", 600, 100, -1, -1, 1 + 32, "", 24) Local $nResultado = _SQLite_GetTable2d($hBD_Disco, "SELECT * FROM Dados;", $aConsulta, $nLinhas, $nColunas) Sleep(1000) SplashOff() ; importa os dados If $nResultado = $SQLITE_OK Then Local Enum $DB_NUMEROS ProgressOn("Atenção!", "Carregando banco de dados...", "0%") _SQLite_Exec($hBD_Mem, "CREATE TABLE IF NOT EXISTS Dados (Numeros TEXT);") For $nIndice = 1 to $nLinhas ProgressSet($nIndice / $nLinhas * 100, Round($nIndice / $nLinhas * 100, 2) & '%') _SQLite_Exec($hBD_Mem, 'INSERT INTO Dados (Numeros) VALUES ("' & $aConsulta[$nIndice][$DB_NUMEROS] & '");') Next ProgressSet(100, '100%') Sleep(250) ProgressOff() EndIf ; fecha tudo _SQLite_Close($hBD_Mem) _SQLite_Close($hBD_Disco) _SQLite_Shutdown()
  3. Criar e ler um banco de dados SQlite

    Entendi a questão da memória, mas daí não tem jeito de fazer isso diretamente. Vc trá que criar um "clone" do banco em memória e importar o conteúdo do BD em disco e a partir daí trabalhar só com o da memória. E se necessário, fazer as alterações em disco a medida que acontecem. Eu tenho um script assim. Ao iniciar, carrego todo o banco em memória, daí todas as consultas são no BD em memória e faço as gravações (eventuais) em disco simultaneamente. E os cartões? Como são divididos?
  4. Criar e ler um banco de dados SQlite

    Outra coisa. Quem fez o post americano tbm não entendia muito de BD ou estava começando. Em teoria, os passos são: vc abre o BD cria as tabelas internas e os relacionamentos inclue, altera, exclue ou consulta dos dados Os passos 1 e 2 ocorrem apenas uma vez, já o 3o passo ocorre gradativamente. Por isto que eu me arrepio quando vejo o código postado. If Not FileExists("database.db") Then $dbn = _SQLite_Open("database.db") _SQLite_Exec($dbn, "CREATE TABLE Dados (Numeros);") For $i = 1 To 10 $dados = "PM-S" & $i & "=02 05 06 08 15 20 23 26 28 30 35 36 38 43 45 47 52 54 55 56 66 68 71 74 75 PM-Q" & $i & " 10" $sql = "INSERT INTO Dados VALUES('" & $dados & "');" ;_Base_Execute($sql) _SQLite_Exec($dbn, $sql) Next Else $dbn = _SQLite_Open("database.db") EndIf Para começo de conversa, qual a diferença entre as linhas de abertura do BD com o _SQLite_Open? Se não existe o arquivo físico, abre o banco! E se existe, abre o banco? Não se deve confundir a abertura e criação do BD com sua manutenção. Eu faria assim: ; seção de abertura do BD $dbn = _SQLite_Open("database.db") _SQLite_Exec($dbn, "CREATE TABLE IF NOT EXIST Dados (Numeros TEXT);") ; seção de inclusão de dados For $i = 1 To 10 $dados = "PM-S" & $i & "=02 05 06 08 15 20 23 26 28 30 35 36 38 43 45 47 52 54 55 56 66 68 71 74 75 PM-Q" & $i & " 10" $sql = "INSERT INTO Dados VALUES('" & $dados & "');" _SQLite_Exec($dbn, $sql) Next Observe: a clásula IF NOT EXIST no comando CREATE TABLE (assim cria somente se a tabela não existir, evitando que a tabela seja zerada toda vez) o tipo TEXT para definição do campo Numeros. Apesar de opcional, é sempre importante colocar. Neste caso, o BD seria aberto, criado se necessário o arquivo físico e a(s) tabela(s) internas. Em um segundo momento, os dados seriam incluídos. Claro que olhando para o script, os dados seriam inclusos sempre, por isso que a inclusão só poderia acontecer em um script separado para alimentar o BD inicialmente (recomendado) ou uma condição que permitisse a inserção dos dados na tabela apenas uma única vez. ; seção de abertura do BD $dbn = _SQLite_Open("database.db") _SQLite_Exec($dbn, "CREATE TABLE IF NOT EXIST Dados (Numeros TEXT);") Local $aRegistro ; verifica se tem alguma coisa no BD _SQLite_QuerySingleRow($dbn, "SELECT COUNT(Numeros) FROM Dados;", $aRegistro) If $SQLITE_OK and not $aRegistro[0] Then ; se não existir NENHUM cartão, insere os dados ; seção de inclusão de dados For $i = 1 To 10 $dados = "PM-S" & $i & "=02 05 06 08 15 20 23 26 28 30 35 36 38 43 45 47 52 54 55 56 66 68 71 74 75 PM-Q" & $i & " 10" $sql = "INSERT INTO Dados VALUES('" & $dados & "');" _SQLite_Exec($dbn, $sql) Next EndIf Ok, agora temos um procedimento adequado para criar e inserir os dados (se necessário). Para criar um BD em memória basta mudar a linha $dbn = _SQLite_Open("database.db") para $dbn = _SQLite_Open() Porém, daí todos os dados colocados no BD desaparecerão quando e se o programa fechar ou a máquina desligar/reiniciar, etc Em compensação, as operações são super rápidas. Mas eu acho que a sua cartela pode ser desdobrada em campos menores. Seguindo o post anterior, me explique tbm o que são os nros? PM-S 1,2,3, etc - o que é? = 02 05 06 08 etc - imagino que são os nros sorteados na cartela PM-Q 1,2,3, etc - o que é? Pensei numa ideia maluca aqui, vamos ver se vinga ;)
  5. Criar e ler um banco de dados SQlite

    Que pena que perdemos as msgs anteriores, mas fazer o que... Queria entender um pouco mais sobre esta questão de "gerar os cartões" que totalizariam 2 milhões de linhas. Estes cartões já estão gerados? Estão em um arquivo INI, isso? E vc quer importar para um BD? Se for assim, o procedimento de leitura do INI e gravação no BD vc já tem. Será demorado? Provavelmente, mas como vc mesmo disse, é uma operação que pode ser feita "off-line", ou seja, o cliente nunca vai saber que aconteceu. Vc já vai chegar com o BD pronto para ele. Mas a minha pergunta é exatamente essa! É necessário gravar todos estes cartões antecipadamente? Como funciona um bingo na prática? Faça de conta que vc não tem nenhum cartão gerado. Primeira vez que vc entrou num bingo. São gerados quantos cartões? Ficam gravados porque? PS. Quanto à dúvida técnica do BD em memória, basta não utilizar nenhum parâmetro no comando _SQLite_Open, daí o BD é gerado em memória.
  6. SQLite Básico

    @Belini Não entendi a questão de não conseguir abrir o banco de dados. Como assim? Preste atenção que um arquivo de banco de dados no SQLite (ou outro bando de dados) não é como um arquivo convencional! A melhor analogia que podemos utilizar é que o "arquivo físico do banco de dados" é como se fosse um arquivo tipo ZIP, por exemplo. Como arquivo ele é inútil, mas dentro dele é que tem os arquivos que precisamos. Da mesma forma funciona um arquivo de banco de dados. Ao criarmos um arquivo "físico" não podemos simplesmente sair utilizando o mesmo, como se fosse um arquivo TXT. É necessário criar as TABELAS dentro do arquivo. Daí finalmente, pode-se incluir, alterar, deletar ou consultar os dados. A maioria das pessoas (eu inclusive) quando comecei com banco de dados, não sabia disso. Tinha uma noção, mas só na prática que fui entender corretamente o SQLite. Hoje não abro mais mão de trabalhar com ele. Finalmente, pela mensagem de erro que vc postou antes: Eu diria que com 99% de certeza que vc está utilizando a DLL errada para o ambiente que vc está trabalhando. O comando de inicialização do SQLite - comando _SQLite_Startup() - é um saco de trabalhar porque ele é pouco intuitivo. Quando dá erro, todas as operações subsequentes não funcionam. No seu caso, a primeira coisa a identificar é o ambiente! É 32 ou 64 bits? E se vc está forçando seu script a trabalhar em qual ambiente? Segunda coisa: os parâmetros do _SQLite_Startup(). Tem duas situações: 1) se não passar nenhum nome como parâmetro ele assume obrigatoriamente os nomes SQLITE3.DLL para ambiente 32 bits e SQLITE3_X64.DLL para ambiente 64 bits quaisquer outros nomes NÃO FUNCIONAM! Dá erro e não inicializa o SqLite! Que acaba dando a msg que vc postou! Outra coisa muito importante, estes arquivos DEVEM estar preferencialmente na mesma pasta do script. A sequência de procura das DLLs é @ScriptDir, @SystemDir, @WindowsDir e @WorkingDir. Quando não acha na pasta do script, vai na pasta @systemdir, depois @windowsdir e finalmente na @workingdir. E novamente os nomes são obrigatoriamente os descritos acima! 2) se passar o nome da DLL a ser aberta e o ambiente for 64 bits, o próprio AutoIt vai acrescentar o sufixo _X64 em qualquer nome que for passado! Isto é um pseudo-bug do AutoIt! Exemplo: _SQLite_Startup("F:\MeuArquivo.Dll") Neste caso, se o ambiente for 32 bits e o arquivo "MeuArquivo.Dll" existir no drive F: a SQLite será inicializada. MAS se for ambiente 64 bits, o sufixo _X64 será incluído automaticamente (pseudo-bug do AutoIt) e o arquivo a ser procurado será o MeuArquivo_X64.Dll, ocasionando um erro porque o arquivo especificado como argumento não existe (ou não foi encontrado). Acredito que este seja o motivo do erro no seu caso. Apesar disto tudo estar escrito no 1o post, acho que não ficou bem claro! Falha minha. Peço desculpas por isso! E por último, quando falamos em forçar o ambiente (32 ou 64 bits) é muito importante que isto esteja bem claro desde o começo em nossos scripts, pois gera uma fonte interminável de dores de cabeça. Independente do ambiente que vc trabalha (não confundir com o ambiente onde vai executar o script depois de pronto), é muito esclarecedor para o script (e para nós mesmos) que tenhamos certeza de onde estamos pisando! Eu pessoalmente utilizo a diretriz #AutoIt3Wrapper_UseX64=n Para informar ao AutoIt qual é o meu ambiente de desenvolvimento. Sempre em 32 bits! Assim, eu garanto que, se eu compilar para teste ou compilar final meu script sempre vai rodar em 32 bits em qualquer ambiente (32 ou 64), e por tabela as DLL associadas também devem ser em 32 bits. Isto interfere um monte no ambiente que está sendo executado, como na macro @ProgramFiles, que pode ser C:\Program Files ou C:\Program Files (x86) ou DLLs a serem carregadas,. Até mesmo a pasta do sistema @SystemDir é afetada, pois pode ser tanto C:\Windows\System32 ou C:\Windows\SysWOW64 Então se o seu script vai rodar em 32 ou 64 bits, tenha certeza que fazer as modificações adequadas no código para evitar confusão depois! Utilize a macro @AutoItX64 par garantir isso. Depois que eu percebi este detalhe e passei a controlar o ambiente, e não deixar por conta, tive trocentos problemas a menos com DLLs e arquivos. Por exemplo, ao procurar por atualização de um arquivo no servidor, sendo que o seu script diferencia o ambiente: Local $sArquivo = "MeuArquivo.Dll" If @AutoItX64 Then $sArquivo = "MeuArquivo64.Dll" If not BAIXAR_ARQUIVO($sArquivo) Then ConsoleWrite('Erro" & @CRLF) Boa sorte!
  7. Ok, então provavelmente está ocorrendo o seguinte: Vc deve estar usando uma versão da DLL diferente da relacionada na documentação! Tipo, as DLLs tbm tem atualização e correção, e são atualizadas junto com as atualizações do Windows. Provavelmente vc deve estar usando uma mais desatualizada (WinXP) e a documentação foi evoluindo até a versão final, que foi no Win7 (se não me engano). Minha recomendação é tentar encontrar outra versão mais atualizada desta mesma DLL, talvez até em Windows mais novos, mas sempre de 32 bits. Quando funcionar o comando acima (movie text show) deve fucionar tbm o comando de stretch! Veja a versão que vc tem (em propriedades, detalhes), veja se consegue encontrar outra, talvez no SP3 ou Win7 e finalmente veja se funciona!
  8. Fui procurar a sintaxe do comando Window e a opção de stretch aparece lá. Faz assim, testa este outro comando, para ver se a função reconhece _mciSendString('window movie text "JukeBel" state show')
  9. Incorporar libmpv no programa

    Show de bola. Parabéns!
  10. Incorporar libmpv no programa

    E Músicas estão incomodando? Ou só os vídeos?
  11. Incorporar libmpv no programa

    Mas não converte tudo, nem precisa. Converta os que incomodam. Aqueles que os clientes reclamam ou aqueles que vc "pescou" numa passada de teste. Realmene não há como trabalhar uma biblioteca deste tamanho!
  12. Incorporar libmpv no programa

    Isso mesmo Mutleey. Foi este o ponto quando comentei que o Belini tem controle sobre o que executa no programa dele. Como o acervo dele (e dos demais) são digamos, entregues pelo desenvolvedor, ao instalar o programa, vc instala tbm o acervo digital. Assim, quaisquer arquivos (vídeo ou áudio) que não toquem, basta transcodificar para um formato "tocável" e substituir o original que não funciona. E isso pode ser feito "offline", no sentido de fazê-lo no momento da escolha e seleçào do acervo a ser dispnibilizado. Já no meu caso, que depende de arquivos do cliente, daí tenho que recorrer ao plaer universal, por enquanto, o MPV.
  13. Incorporar libmpv no programa

    Exatamente por isso que, por enquanto, eu escolhi o MPV como player de fundo. Em determinados casos, as mídias abrem no MCI e não abrem no DS, ou vice-versa. Em outros, tem que atualizar os codecs, outros não. Testei a WMP e até o MPC. Em um teste em outro computador aqui no escritório, o MCI parou de funcionar "do nada". Atualizei codecs, troauei de pacote, fiz macumba e nada. Lá pelas tantas, voltou a funcionar. Enquanto testava o DS e o MPV, parou de funcionar de novo. O VLC foi em promissor, mas eu achei a dcumentação falha e em alguns casos não tocou o vídeo (me surpreendeu!) e o principal fator decisivo para mim foi a questão tamanho (quase 70Mb) para baixar. Assim, nos meus testes o MPV foi o mais confiável, sem depender de codecs externos. Rodou todos os tipos de mídia (áudio e vídeo) com os recursos que eu preciso (mute, volume mais e menos, seek, pause, play, stop, informações - tamanho, duração, etc) e inclusive as funções de playback em outro termpo (mais acelerado ou mais lento) que em outros players não funcionava (e eu achava que era do codec ou to tipo de vídeo que não aceitava), funcionou blz tbm. Ainda estou efetuando testes em todas as máquinas que consigo por a mão. Quando vou em clientes, peço licença para rodar um teste com o MPV. Até agora, tem rodado tudo em todos os lugares. Não estou modificando nada, nem instalando nada. Só para verificar se os vídeos rodam independente do ambiente (Win7, Win8, Win10 32) todos 32 ou 64 bits, com ou sem codecs instalados. Somente assim, terei a certeza (relativa) de que vou me incomodar menos com a próxima versão, do que estou me incomodando agora! 99% por causa de arquivso que não tocam, provavelmente codecs. Mas não tem como ficar atendendo todo mundo, dando suporte mesmo quando vc instala um pacote de codecs e mesmo assim ora funciona ora não funciona. Novamente recomendo, por enquanto, o MPV. Em várias conversas e testes com o Belini (sim, conversamos bastante), infelizmente o MPV não funciona no caso dele em virtude do ambiente WIn XP, que já não é o meu caso. E aliás, o software do Belini, para quem não conhece, é um baita programa. Muito completo e bem-feito! Mas #FikaADika
  14. nomear e chamar variaveis

    Olá Bllee. Existem vários métodos para nomear variáveis, cada um utiliza o que mais gosta, mas isto é muito pessoal mesmo. Posso recomendar a nomenclatura oficial = https://www.autoitscript.com/wiki/Best_coding_practices#Names_of_Variables Eu normalmente sigo o modelo oficial porque depois para fins de depuração e manutenção, fica bem mais fácil. Em relação aos arrays (ou vetores ou matrizes), ainda prefiro utilizar o comando ENUM para facilitar a visualização do código e deixar mais prático de trabalhar. Até porque se precisar mudar as posições de lugar (inserir ou remover tbm) é mais ácil mudar a linha do ENUM do que mudar todo o código. Exemplo: Local Enum $eX_POS, $eY_POS Local $aPosicao = MouseGetPos() Local $nPontoX = $aPosicao[$eX_POS] Local $nPontoY = $aPosicao[$eY_POS] Outro exemplo: #include <Misc.au3> #include <MsgBoxConstants.au3> Local Enum $eKEY_CODE, $eKEY_DESCRIPTION Local $aKeyboard = [ [ "01", "Left mouse button" ], _ [ "02", "Right mouse button" ], _ [ "03", "Control-break processing" ], _ [ "04", "Middle mouse button (three-button mouse)" ], _ [ "05", "X1 mouse button" ], _ [ "06", "X2 mouse button" ], _ [ "08", "BACKSPACE key" ], _ [ "09", "TAB key" ] ] ... Local $nTecla = CHECK_KEYBOARD() For $nIndice = 0 to UBound($aKeyboard)-1 If $nTecla = $aKeyboard[$nIndice, $eKEY_CODE] Then MsgBox($MB_OK, "Info", "Vc pressionou: " & $aKeyboard[$nIndice, $eKEY_DESCRIPTION]) Next ... Ainda é possível também utilizar o conceito de ESTRUTURAS, mas é um pouquinho mais complexo, mas fica bem parecido com a tua intenção original. Veja um exemplo que o nosso colega Rogrigo Chaves Neto utilizou em um de seus scripts
  15. UDF para rodar vídeos

    Os volumes da saída de som, não dos microfones... Destes eu não sei. Falo isto porque tinha antigamente no XP uma aplicação de teste de transparência que eu tinha feito para mostrar a palavra MUDO quando mutasse o som da máquina, tipo um indicativo visual mesmo, mas o objetivo real era testar a transparência da janela. Quando fui para o Windows 7, eu percebi que o controle de volume master (que funcionava no XP) era diferente. Como era apenas um teste, nunca fui atrás. Mas lembrei do assunto vendo a discussão de vcs. Tbm não tenho o conhecimento e a experiência de vcs no assunto som, vídeo, jukeboxes e afins, assim posso apenas estar dando um balão ;)
×