GURUS - OTIMIZACAO DE CODIGO
Saudações,
Sobre eficiência. Quando comecei a ler o tópico, pensei pouco poderei ajudar, pelo contrário aprendi mais um pouco com os 2 link's que colocaram sobre eficiência.Liguei eficiência mais para a velocidade do algoritmo. E por tras disso tem um mostro enorme. Mas continuando a ler, vi que o tópico seria mais além, não somente eficiencia em termos de código rápidos e sim códigos bem modelados.
Agora o que seria realmente eficiência:
1)Ele sendo rápido, usando pouco mémoria, tempo de resposta melhor ?
2)Seria um código bem modelado?
Acreditem ambos são inversamente proporcional. Gerar um código rápido mata modelagem e vice-versa.
Só para ter uma ideia, salto é o que tem de mais ineficiente e usamos em 90% do código.E porque é ineficiente. Bem um pouco de teoria chata, ao carregar um programa ele não vai inteiro para MP, e sim inteiro para MS (memoria secundaria) que seria a memoria Virtual.
Bem o processador "só fala" (entre aspas pq o processador na verdade só fala com os registradores internos, mas pulamos essa parte) com a MP.
Então o seu codigo exe é separado em pedaços (processos) e carregado na MP. Cada processo tem direito a uma parcela da MP.
Então esses pedaços são separados adotando o principio de localidade ( que os códigos a serem usados estão perto uns dos outros). Tendo um salto o risco do código que esta sendo chamado não estiver na MP é grande, então descarrega MP ,pega da MS e continua processando.
Então se vc quiser evitar salto adeus O.O e Modelagem. Sendo que os compiladores são bem "espertos" e tentam ao maximo, por exemplo não separa o inicio de um FOR em um pedaço e o final em outro pedaço por que senão a troca de MP para MS seria para cada repetição do FOR.
Logo eu não me preocupo muito com a eficiencia 1), até pq os programas que faço são "triviais", o que quero dizer são programas comerciais, com uso de dados. Não faz calculos complexo, não usa matrizes ou array grandes, logo não tem o que otimizar. As dicas que li nos dois link's são interessantes, mas na hora que estou desenvolvendo um projeto como já foi colocado pela maioria o FOCO é a modelagem.
Sobre eficiência. Quando comecei a ler o tópico, pensei pouco poderei ajudar, pelo contrário aprendi mais um pouco com os 2 link's que colocaram sobre eficiência.Liguei eficiência mais para a velocidade do algoritmo. E por tras disso tem um mostro enorme. Mas continuando a ler, vi que o tópico seria mais além, não somente eficiencia em termos de código rápidos e sim códigos bem modelados.
Agora o que seria realmente eficiência:
1)Ele sendo rápido, usando pouco mémoria, tempo de resposta melhor ?
2)Seria um código bem modelado?
Acreditem ambos são inversamente proporcional. Gerar um código rápido mata modelagem e vice-versa.
Só para ter uma ideia, salto é o que tem de mais ineficiente e usamos em 90% do código.E porque é ineficiente. Bem um pouco de teoria chata, ao carregar um programa ele não vai inteiro para MP, e sim inteiro para MS (memoria secundaria) que seria a memoria Virtual.
Bem o processador "só fala" (entre aspas pq o processador na verdade só fala com os registradores internos, mas pulamos essa parte) com a MP.
Então o seu codigo exe é separado em pedaços (processos) e carregado na MP. Cada processo tem direito a uma parcela da MP.
Então esses pedaços são separados adotando o principio de localidade ( que os códigos a serem usados estão perto uns dos outros). Tendo um salto o risco do código que esta sendo chamado não estiver na MP é grande, então descarrega MP ,pega da MS e continua processando.
Então se vc quiser evitar salto adeus O.O e Modelagem. Sendo que os compiladores são bem "espertos" e tentam ao maximo, por exemplo não separa o inicio de um FOR em um pedaço e o final em outro pedaço por que senão a troca de MP para MS seria para cada repetição do FOR.
Logo eu não me preocupo muito com a eficiencia 1), até pq os programas que faço são "triviais", o que quero dizer são programas comerciais, com uso de dados. Não faz calculos complexo, não usa matrizes ou array grandes, logo não tem o que otimizar. As dicas que li nos dois link's são interessantes, mas na hora que estou desenvolvendo um projeto como já foi colocado pela maioria o FOCO é a modelagem.
Sobre algumas coisas que li nesse topico
Bem dar pau não vai, mas tem como vc declarar a variavel sem ele ser alocada a cada momento que vc chamar o procedimento, é com o uso STATIC.
Static Var as string
Declarando com Static a variavel só é alocada uma unica vez e armazena o seu valor para a proxima vez que for chamada o procedimento. E ela só é desalocada quando o procedimento for desalocado, isto é quando sair do escopo do procedimento.
Da para fazer um contador do tipo
Agora eu não uso isso. Quando identifico um caso que preciso armazenar o valor para os proximas chamadas, penso logo em variavel public ao modulo ou passagem por referencia.
VB não é orientado a objeto e esta meio longe de ser. Para ser O.O tem que ter Classe,Encapsulamento, Polimorfismo, Herança.
Bem o VB oferece classe e Encapsulamento mas não oferece Polimorfismo e Herança e esses dois são fundamentais em uma O.O
E no caso da classe ele peca muito, pois o construtor da classe é ruim, não permite sobrescrever o construtor e nem inicializar passando variaveis.
Programar em uma linguagem O.O vc sente uma diferença incrivel comparando com o VB e até Delphi ( que é hibrido).
Fiz um projeto em JAVA onde tudo é classe e vc de forma alguma pode ir direto para codificar. Programando em VB, por exemplo, vc precisa fazer uma função que conta, pois bem no mesmo modulo do form vai lá e declara a função codifica e vai embora. Isso no meio do desenvolvimento, vc não precisa pensar muito aonde vai colocar essa função.
Em Java, não o principal é saber aonde encaixar essa função. Como é totalmente O.O parece que o projeto acaba se encaixando sozinho, pq se vc colocar um metodo erradamente em uma classe, usar esse método fica dificil e até não poder usar. Mas se vc colocar na classe correta o codigo se encaixa.
Então VB 6 não é O.O , apenas da uma palhinha, na verdade ele permite construção de TAD, pois vc consegue fazer uma estrutura de dados, encapsular e fazer com que o usuário só use os metodos que desejar sem poder estragar sua estrutura. E O.O permite isso e mais um monte de outras coisas.
Agora o .NET é O.O
Citação:o tbn ATUALIZAR é utilizado com frequencia, toda vez que ele for clicado, as variáveis são declaradas novamente? isso pode gerar algum pau no meu prog?
Bem dar pau não vai, mas tem como vc declarar a variavel sem ele ser alocada a cada momento que vc chamar o procedimento, é com o uso STATIC.
Static Var as string
Declarando com Static a variavel só é alocada uma unica vez e armazena o seu valor para a proxima vez que for chamada o procedimento. E ela só é desalocada quando o procedimento for desalocado, isto é quando sair do escopo do procedimento.
Da para fazer um contador do tipo
Private Sub Teste()
Teste1'Retorna 1
Teste1'Retorna 2
Teste1'Retorna 3
end Sub
Private Function Teste1() as Long
Static var as Long
var=var+1
Teste1=var
end SubAgora eu não uso isso. Quando identifico um caso que preciso armazenar o valor para os proximas chamadas, penso logo em variavel public ao modulo ou passagem por referencia.
Citação:Na verdade o VB é então uma RQD (Rapid Quebra-Galho Development em vez de RAD)
Pois como o LCSD citou, nunca se sabe 100% o que vai acontecer...
e o VB.net será que é relamente ORIENTADO a OBJETIVO como já vi alguns citarem?
VB não é orientado a objeto e esta meio longe de ser. Para ser O.O tem que ter Classe,Encapsulamento, Polimorfismo, Herança.
Bem o VB oferece classe e Encapsulamento mas não oferece Polimorfismo e Herança e esses dois são fundamentais em uma O.O
E no caso da classe ele peca muito, pois o construtor da classe é ruim, não permite sobrescrever o construtor e nem inicializar passando variaveis.
Programar em uma linguagem O.O vc sente uma diferença incrivel comparando com o VB e até Delphi ( que é hibrido).
Fiz um projeto em JAVA onde tudo é classe e vc de forma alguma pode ir direto para codificar. Programando em VB, por exemplo, vc precisa fazer uma função que conta, pois bem no mesmo modulo do form vai lá e declara a função codifica e vai embora. Isso no meio do desenvolvimento, vc não precisa pensar muito aonde vai colocar essa função.
Em Java, não o principal é saber aonde encaixar essa função. Como é totalmente O.O parece que o projeto acaba se encaixando sozinho, pq se vc colocar um metodo erradamente em uma classe, usar esse método fica dificil e até não poder usar. Mas se vc colocar na classe correta o codigo se encaixa.
Então VB 6 não é O.O , apenas da uma palhinha, na verdade ele permite construção de TAD, pois vc consegue fazer uma estrutura de dados, encapsular e fazer com que o usuário só use os metodos que desejar sem poder estragar sua estrutura. E O.O permite isso e mais um monte de outras coisas.
Agora o .NET é O.O
Mais um pouquinho...rs
Bem sobre modelagem, O uso de varios modulos foge da eficiência mas ganha em modelagem, e com isso reuso e eficiência na codificação. Fica mais arrumado. Tenho um projeto que tem uns 40 modulos...rs..
E fui diminuindo com o uso de Classe, é muito melhor para modelagem, o código fica muito mais arrumado.Mas ainda não conseguir acabar com os 40.
Em projetos novos, uso o Modulo para somente algumas rotinas que tem que ser publicas e variaveis. Não uso mais modulo, para modular o programa, do tipo, ao invez de criar um Modulo Cliente, crio uma Classe cliente. Então com isso só uso dois Modulos, um para variaveis e outro para procedimentos que não modulei em Classes. Seria aquelas funções largadas, que se fosse fazer por classe a classe só teria um metodo.
Bem evito variaveis globais nos blocos dos Form's,quando preciso incluo com uma propriedade do Form.
Ex: no bloco do form declare
Preste atenção aos nomes das variaveis, criar uma prefixo é interessante do tipo
p ( de publica), l ( para publica no bloco), ( sem nada para variaveis dentro de Sub ou function)
Obj ( objeto),Var ( para variavel),Const( para constante)
Nome ( uso um nome que dica claramente o que é a variavel)
Assim vc só vendo o nome da variavel já se situa em relação ao escopo e o que ela é, e pelo nome para que ela serve.
Isso vc pode criar a sua propria sintaxe de declaração. E pode ir mais longe, identificar o tipo da variavel, eu não fui tão longe apenas tabelei objeto, se é uma variavel e se é uma constante.
Ex:
pVarPathBanco
pVarConBanco
lObjCliente
Outra coisa, é documentar, na hora que vc esta fazendo sabe o que esta fazendo e cada linha do codigo, passou um tempo dependendo no tamanho da criança vc já tem que pensar um pouco para lembrar o que fez, passando uns meses, anos é mais facil apagar e fazer outro do que entender o que foi feito...então documente, use nomes coerentes e tenta arrumar o codigo pensando no reuso. Do Tipo vc fez um cadastro de clientes, se vc quiser usar ele em outro projeto é possÃvel? Ou vc tera que carregar junto com o código varias coisas particulares do projeto em questão...preocupando-se com isso na hora que estiver codificando já vai desenvolver codigos mas eficientes para reuso, com isso mais modelados.
Agora para aqueles que estão começando, nada melhor que um livro de Estrutura de Dados para começar.
Bem sobre modelagem, O uso de varios modulos foge da eficiência mas ganha em modelagem, e com isso reuso e eficiência na codificação. Fica mais arrumado. Tenho um projeto que tem uns 40 modulos...rs..
E fui diminuindo com o uso de Classe, é muito melhor para modelagem, o código fica muito mais arrumado.Mas ainda não conseguir acabar com os 40.
Em projetos novos, uso o Modulo para somente algumas rotinas que tem que ser publicas e variaveis. Não uso mais modulo, para modular o programa, do tipo, ao invez de criar um Modulo Cliente, crio uma Classe cliente. Então com isso só uso dois Modulos, um para variaveis e outro para procedimentos que não modulei em Classes. Seria aquelas funções largadas, que se fosse fazer por classe a classe só teria um metodo.
Bem evito variaveis globais nos blocos dos Form's,quando preciso incluo com uma propriedade do Form.
Ex: no bloco do form declare
Private ClsCodRelatorio As Long 'Codigo do relatorio
Public Property Get CodRelatorio() As Long
CodRelatorio = ClsCodRelatorio
End Property
Public Property Let CodRelatorio(ByVal Dado As Long)
ClsCodRelatorio = Dado
End Property
Me.CodRelatorio'Para acessar
Preste atenção aos nomes das variaveis, criar uma prefixo é interessante do tipo
p ( de publica), l ( para publica no bloco), ( sem nada para variaveis dentro de Sub ou function)
Obj ( objeto),Var ( para variavel),Const( para constante)
Nome ( uso um nome que dica claramente o que é a variavel)
Assim vc só vendo o nome da variavel já se situa em relação ao escopo e o que ela é, e pelo nome para que ela serve.
Isso vc pode criar a sua propria sintaxe de declaração. E pode ir mais longe, identificar o tipo da variavel, eu não fui tão longe apenas tabelei objeto, se é uma variavel e se é uma constante.
Ex:
pVarPathBanco
pVarConBanco
lObjCliente
Outra coisa, é documentar, na hora que vc esta fazendo sabe o que esta fazendo e cada linha do codigo, passou um tempo dependendo no tamanho da criança vc já tem que pensar um pouco para lembrar o que fez, passando uns meses, anos é mais facil apagar e fazer outro do que entender o que foi feito...então documente, use nomes coerentes e tenta arrumar o codigo pensando no reuso. Do Tipo vc fez um cadastro de clientes, se vc quiser usar ele em outro projeto é possÃvel? Ou vc tera que carregar junto com o código varias coisas particulares do projeto em questão...preocupando-se com isso na hora que estiver codificando já vai desenvolver codigos mas eficientes para reuso, com isso mais modelados.
Agora para aqueles que estão começando, nada melhor que um livro de Estrutura de Dados para começar.
Aff, me incluiram na lista do neerds , aÃ, aà [S55]...
Bom, valeu pelo reconhecimento, não sou uma fera, mas algumas dicas que já quebrou o maior galho para mim, e melhorou a minha forma de desenvolver [S25]...
Padronização do nomes é importante colocar os nome dos objetos a trabalhar , mas coloca-lo de uma maneira que você ou outro desenvolvedor possa entender ... já fiz um artigo sobre isto (PADRONIZAÇÃO, UM BEM NECESSà ÂRIO pois já peguei projetos que tinha objetos de nome listadeclientesaselecionar, em um combo (?!?) [S52] , e comentar cada parte do código, para depois não ficar perdendo tempo tentando advinhar o que aquilo siginifica ...
Pesquisa de apis quando você for trabalhar com uma api, sempre pesquise , pois sempre existe varios tipo de api para fazer ou executar uma funcionalidade,para ver qual é a mais rápida, e mais estável, verificar se a mesma funciona na versão do windows no qual o programa vai trablhar ; outra dica, é controlar o numero de apis, pois tem gente que enfia api até não dar mais, e no final, o projeto trava ... e o cara não sabe o porque
Uso de ocx: só use uma ocx, se ela for extremamente necessária, caso não for, não a utilize. Existe ótimas ocxs por aÃ, o problema é que sempre uma ou outra acaba dando problema, ou na instalação ou porque ela não é compativel com a versão do win (tem um monte que traba no xp) ou com outro componente ... pesquise e estude mais, pode-se substituir uma determinada ocx, construindo vc mesmo um usercontrol, ou utilizando classes ...
aà estão as dicas, são coisas que não tem tanto mistério e nem precisa ser um guru para entender, mas que fazem a diferênça ... [S85]
Bom, valeu pelo reconhecimento, não sou uma fera, mas algumas dicas que já quebrou o maior galho para mim, e melhorou a minha forma de desenvolver [S25]...
aà estão as dicas, são coisas que não tem tanto mistério e nem precisa ser um guru para entender, mas que fazem a diferênça ...
Tio Max(Mummy é aquele seu antepassado que lhe faz bolinhos de chuva), fazendo jus à  alcunha de Fiscal, põe à  prova a afirmação do Renato...
...e abre a oficina. Joguei na bancadinha de testes o seguinte:
- Um form com dois botões
- Um módulo com uma Sub pública que não faz absolutamente nada
- A classe-cronà 'metro PerformanceTimer, minha companheira inseparável
Um dos botões dispara o cronà 'metro, faz um loop vazio de 1 a 100000 e pára o cronà 'metro. O segundo dispara o cronà 'metro, faz um loop de 1 a 100000 que chama a Public Sub do módulo (que não faz nada) e pára o cronà 'metro. Só pra comparar o tempo perdido para se chamar um módulo. Resultados:
Sem módulo: 0,002 s
Com módulo: 0,038 s
Análise
Apesar da grande diferença (19 vezes), é bom observar que pedimos 100000 acessos ao módulo (coisa não muito comum, certo?). Creio que, em números absolutos, a chamada de módulos não traga muita perda de performance, pois não é acumulativa, como nas pesquisas em BD. A não ser que caiamos na armadilha das memórias e do princÃpio da localidade, bem explanados pelo colega Renato no post 43 deste tópico. Mesmo assim, acredito que raros serão os casos em que chegaremos a uma perda de performance acusada pelo usuário.
Conclusão (a partir do teste acima)
O custo/benefÃcio da modelagem sobre a eficiência ainda aconselha a utilização de módulos. O teste não é conclusivo, pois os loops não agregaram nenhuma funcionalidade (ver post #0043 e as consequências dos "saltos"). Estarei ocupado agora, dando comida pros cachorros e levando o lixo pra fora, de modo que conto com os colegas para que novos testes sejam postados aqui, com novas situações.
Citação:O uso de varios modulos foge da eficiência mas ganha em modelagem, e com isso reuso e eficiência na codificação. Fica mais arrumado. Tenho um projeto que tem uns 40 modulos...rs..
...e abre a oficina. Joguei na bancadinha de testes o seguinte:
- Um form com dois botões
- Um módulo com uma Sub pública que não faz absolutamente nada
- A classe-cronà 'metro PerformanceTimer, minha companheira inseparável
Um dos botões dispara o cronà 'metro, faz um loop vazio de 1 a 100000 e pára o cronà 'metro. O segundo dispara o cronà 'metro, faz um loop de 1 a 100000 que chama a Public Sub do módulo (que não faz nada) e pára o cronà 'metro. Só pra comparar o tempo perdido para se chamar um módulo. Resultados:
Sem módulo: 0,002 s
Com módulo: 0,038 s
Análise
Apesar da grande diferença (19 vezes), é bom observar que pedimos 100000 acessos ao módulo (coisa não muito comum, certo?). Creio que, em números absolutos, a chamada de módulos não traga muita perda de performance, pois não é acumulativa, como nas pesquisas em BD. A não ser que caiamos na armadilha das memórias e do princÃpio da localidade, bem explanados pelo colega Renato no post 43 deste tópico. Mesmo assim, acredito que raros serão os casos em que chegaremos a uma perda de performance acusada pelo usuário.
Conclusão (a partir do teste acima)
O custo/benefÃcio da modelagem sobre a eficiência ainda aconselha a utilização de módulos. O teste não é conclusivo, pois os loops não agregaram nenhuma funcionalidade (ver post #0043 e as consequências dos "saltos"). Estarei ocupado agora, dando comida pros cachorros e levando o lixo pra fora, de modo que conto com os colegas para que novos testes sejam postados aqui, com novas situações.
Saudações MAX,
Na verdade dependendo do compilador essa chamada de uma sub no modulo pode ter tempo igual a chamada de uma sub que esteja no mesmo bloco do form.
Me lembrei disso depois, pois na hora de gerar o exe, na verdade aonde tiver a chamada de uma sub ele não efetua um salto, pois o compilador coloca o código compilado inteirinho da sub na sua chamada.Ficando assim sequêncial.
Indo um pouquinho mais a fundo, na verdade uma sub pode ter perda de eficiencia caso tenha parametros e variaveis internas, pois devido a isso ganha algumas linhas a mais no código de máquina, para empilhar as variaveis e parametros. Fora isso realmente os saltos não devem ocorrer.
Agora para tirarmos essa dúvida, vamos para a sua bancada de testes. o teste que vc fez foi pelo EXE gerado ou foi pelo VB?
Creio que se for pelo EXE o tempo vai ser "igual"...Fico no aguardo....
Na verdade dependendo do compilador essa chamada de uma sub no modulo pode ter tempo igual a chamada de uma sub que esteja no mesmo bloco do form.
Me lembrei disso depois, pois na hora de gerar o exe, na verdade aonde tiver a chamada de uma sub ele não efetua um salto, pois o compilador coloca o código compilado inteirinho da sub na sua chamada.Ficando assim sequêncial.
Indo um pouquinho mais a fundo, na verdade uma sub pode ter perda de eficiencia caso tenha parametros e variaveis internas, pois devido a isso ganha algumas linhas a mais no código de máquina, para empilhar as variaveis e parametros. Fora isso realmente os saltos não devem ocorrer.
Agora para tirarmos essa dúvida, vamos para a sua bancada de testes. o teste que vc fez foi pelo EXE gerado ou foi pelo VB?
Creio que se for pelo EXE o tempo vai ser "igual"...Fico no aguardo....
Renato,
Bom. Meu teste se limitou a comparar a chamada da sub pública de módulo com o que seria o processamento dentro da própria sub do evento. Não fiz uma sub no mesmo bloco do form, mas, pelos números que obtive, creio que não precisaremos nos preocupar com um improvável tempo crÃtico para o usuário.
Vou acreditar em sua informação de que os saltos não ocorrerão sob as circustà ¢ncias que coloquei, mas fica aà o registro de mais um obstáculo, caso algum colega comece a ficar preocupado com a lerdeza de seu aplicativo...
E não, não gerei executável. Só mandei rodar direto da minha bancadinha vbp mesmo.
Bom. Meu teste se limitou a comparar a chamada da sub pública de módulo com o que seria o processamento dentro da própria sub do evento. Não fiz uma sub no mesmo bloco do form, mas, pelos números que obtive, creio que não precisaremos nos preocupar com um improvável tempo crÃtico para o usuário.
Vou acreditar em sua informação de que os saltos não ocorrerão sob as circustà ¢ncias que coloquei, mas fica aà o registro de mais um obstáculo, caso algum colega comece a ficar preocupado com a lerdeza de seu aplicativo...
E não, não gerei executável. Só mandei rodar direto da minha bancadinha vbp mesmo.
E mais rápido eu dividir um codigo em procedimentos ?
Sub Command1_Click()
VerificaExiste (Text1.text)
VerificaAspas (Text1.text)
AdicionaReg (Text1.text)
End Sub
ou é melhor fazer assim:
Sub Command1_Click()
...
...
...
...
...
...
...
...
End Sub
Sub Command1_Click()
VerificaExiste (Text1.text)
VerificaAspas (Text1.text)
AdicionaReg (Text1.text)
End Sub
ou é melhor fazer assim:
Sub Command1_Click()
...
...
...
...
...
...
...
...
End Sub
DreamPepper,
Era sobre isso que estávamos tratando aà em cima. A diferença é muito pequena entre "fazer tudo dentro da sub do evento" e "fazer picadinho dela, jogando os pedaços para outras subs". No final, o usuário não vai perceber a diferença. Mas o programador, ou quem for fazer a manutenção do programa, com certeza vai sentir a diferença, pois o código fica muuuuuito mais organizado.
Mas, atenção: não basta colocar
Sub Command1_Click()
VerificaExiste (Text1.text)
VerificaAspas (Text1.text)
AdicionaReg (Text1.text)
End Sub
é necessário comentar o que cada bloco faz.
Sub Command1_Click()
VerificaExiste (Text1.text) [txt-color=#008000]'confere se o arquivo existe, e se foi modificado nos últimos 30 dias[/txt-color]
VerificaAspas (Text1.text) [txt-color=#008000]'Retira todas as aspas duplas, mas deixa as simples[/txt-color]
AdicionaReg (Text1.text) [txt-color=#008000]'Abre o BD e joga os registros, mas gera erro se já tiver os mesmos chvNome e chvAtividade[/txt-color]
End Sub
Assim, se você detectar um erro em runtime, vai saber exatamente em qual sub você deverá ir para consertá-lo.
E, novamente: muito cuidado com o tratamento de erro nesses casos!
Era sobre isso que estávamos tratando aà em cima. A diferença é muito pequena entre "fazer tudo dentro da sub do evento" e "fazer picadinho dela, jogando os pedaços para outras subs". No final, o usuário não vai perceber a diferença. Mas o programador, ou quem for fazer a manutenção do programa, com certeza vai sentir a diferença, pois o código fica muuuuuito mais organizado.
Mas, atenção: não basta colocar
Sub Command1_Click()
VerificaExiste (Text1.text)
VerificaAspas (Text1.text)
AdicionaReg (Text1.text)
End Sub
é necessário comentar o que cada bloco faz.
Sub Command1_Click()
VerificaExiste (Text1.text) [txt-color=#008000]'confere se o arquivo existe, e se foi modificado nos últimos 30 dias[/txt-color]
VerificaAspas (Text1.text) [txt-color=#008000]'Retira todas as aspas duplas, mas deixa as simples[/txt-color]
AdicionaReg (Text1.text) [txt-color=#008000]'Abre o BD e joga os registros, mas gera erro se já tiver os mesmos chvNome e chvAtividade[/txt-color]
End Sub
Assim, se você detectar um erro em runtime, vai saber exatamente em qual sub você deverá ir para consertá-lo.
E, novamente: muito cuidado com o tratamento de erro nesses casos!
Bom axo que esse topico eh mto interessante, ja tirei varias coisas daki que vou levar para meus progetos, mas axo que ele eh mais para intermediarios.... eu como iniciane, (que li tudo) entendi 1/3 do que os "gurus" falam... mas eh isso ae, um dia eu aprendo a linguagem de voces...
flw e obrigado
flw e obrigado
Tópico encerrado , respostas não são mais permitidas