Simon Viegas

Basicamente a sugestão seria você focar problema. Primeiro entende, depois resolve. Foque no problema! Qual parte não teria entendido? Tipo: O número da carteira de motorista (caso o usuário digite o número 0, finalizar o programa); Já sabe fazer. É só o número. Número de multas; Idem. É só ler. Valor da cada uma das multas; Opa! Como assim "cada valor"? Não entendi. Seria um subproblema (do problema geral). Eu entendi assim: se foram 3 multas, eu leria o valor de cada uma. Entendi, mas como faço para ler o valor de cada multa?. Ou seja: a dúvida seria especificamente sobre isso. Entende? Daí, pararia para achar algo... com aquilo que já teve contato... por aí vai. Beleza! Uma forma que imagino que poderia ser, seria utilizar um laço de repetição se baseando pela quantidade de multa que eu já li antes. Exemplo: para i de 1 ate qtdMultas faca escreva (" Multa ", i:2, ": ") leia(valorMulta) valorDivida <- valorDivida + valorMulta fimPara Se forem 3 multas, vai ler 3 valores. Para cada valor que ler, já vai fazendo a soma do subtotal. Perceba que tudo deve meio que seguir um fluxo natural... seguir os passos como se fosse fazer na mão mesmo.. utilizando um papel e lápis. O VisualG e o Portugol servem apenas como um mecanismo para automatizar o processo. Mais abaixo posto um código completo para deixar mais claro. Deve ser impresso o número da carteira, o valor da dívida de cada motorista; É isso que tá escrito!!! e ao final da leitura o total de recursos arrecadados (somatório de todas as multas). Idem. Veja um código com uma possível solução: algoritmo "Total de recursos arrecadados no DETRAN" //Descrição: Crie um algoritmo que ajude o DETRAN a saber o total de recursos //que foram arrecadados com a aplicação de multas de trânsito. O algoritmo //deve ler as seguintes informações para cada motorista: //O número da carteira de motorista(caso o usuário digite o número 0, //finalizar o programa); //Número de multas; //Valor de cada uma das multas; //Deve ser impresso o número da carteira, o valor da dívida de cada motorista; //e ao final da leitura o total de recursos arrecadados (somatório de todas as //multas). var cartMotorista, qtdMultas, i : inteiro valorMulta, valorDivida, valorArrecadado : real Inicio enquanto (VERDADEIRO) faca escrevaL(" Informe a carteira de motorista ou 0 para finalizar") leia(cartMotorista) se (cartMotorista = 0) então interrompa() fimSe escrevaL(" Informe o número de multas") leia(qtdMultas) escrevaL(" Informe o valor de cada uma das multas") valorDivida <- 0 para i de 1 ate qtdMultas faca escreva (" Multa ", i:2, ": ") leia(valorMulta) valorDivida <- valorDivida + valorMulta fimPara escrevaL("Carteira de Motorista: ", cartMotorista:1) escrevaL("Valor da dívida : R$ ", valorDivida:1:2) valorArrecadado <- valorArrecadado + valorDivida escrevaL("") escrevaL("") fimEnquanto escrevaL(" Total de recursos arrecadados: R$ ", valorArrecadado:1:2 ) fimAlgoritmo Veja: isso seria uma possível solução completa! Como sabido por nós, não é o foco do fórum. Postei para servir de referência, já que está fazendo outros exercícios. Daí, poderia reanalisar o enunciado e comparando com essa possível solução. Ir tentando entender a lógica aplicada. Tente ir percebendo como tentei seguir exatamente o quê foi proposto no enunciado.. como uma receita de bolo. Pode está "certo", pode está "errado". Mas a ideia é tentar seguir, inicialmente, apenas o que foi pedido! Se entendeu algo diferente, vai refletindo e ajustando detalhes... Qualquer dúvida ou sugestão é só postar No aguardo.

esse ":x" serve para reservar espaços para o valor da variável, ou seja, o valor impresso de i vai ter pelo menos 2 espaços. Teste a execução com outros valores, como 4, 10 etc e veja o comportamento.

Só tentando aprofundar um pouco... Perdão se vou ser ser prolixo, e para quem não me conhece, é o meu jeito mesmo... Tô tentando melhorar.. mas eu não consigo ser mais sintético e aproveitar para treinar a escrita. Vamos lá: Nesse caso, são duas coisas distintas: ser opcional e rodar. Rodar está intrinsecamente relacionado à sintaxe, ou seja, as regras de como um código pode ser escrito no VisualG. Já ser opcional, estaria relacionado à lógica, se os conjuntos de passos implementados estão satisfazendo ao enunciado. São coisas ligadas, mas é preciso entender que são distintas. O programa roda pois não seria requisito da sintaxe. Essa linha é uma instrução solta... É apenas um comando como qualquer outro. Já ser opcional ou não, vou comentar mais abaixo. Pode ser necessário ou não. Tem a ver também com o que comento lá mais abaixo. Entendo o contrário. A ideia seria buscar seguir um bons padrões de projetos... seria evitar que ocorra situações como essa. Meio que vai depender do contexto... Tipo: Não é que "é", mas talvez seria "deveria ser". Lá também mais abaixo tento demonstra que não seria necessário! A ideia seria tentarmos implementar um melhor código possível (sempre para o contexto dele). Só para simplificar: o algoritmo pode está incompleto ou mesmo não tão bem otimizado, por exemplo. Nem por isso estaria "errado". Deixar ou não deixar essa atualização do aux não necessariamente seria um problema. Pode ser "tanto faz". Como diria o comediante: "mais ou menos, mais ou menos"... . De um modo geral, meio que só iria dar problema em uma única situação: se todos os números digitados forem menor ou igual a 0. Caso contrário, o aux vai receber um valor válido, pois algum número iria fazer atualizar o aux. ADENDO: poderia resumir a postagem toda a essa linha acima. Mas queria/quero apenas detalhar os pontos que penso. IMPORTANTE: lembrando que o VisualG já atribui um valor inicial a todas a variáveis globais, portanto, todas as variáveis do tipo inteiro automaticamente já começam com 0. Entendam que isso é um funcionalidade, ou seja, entendo que não era para ser assim, apenas o "desenvolvedor do VisualG achou legal fazer isso". O Pascal, pai do VisualG, e acho que o Delphi também, têm a mesma característica de inicializar variáveis globais, mas nas principais linguagem do mercado isso meio que não ocorre!!! Seria preciso sempre* inicializar manualmente em algum momento, se não o código não compila ou ficam apresentando alertas (warning) informando que pode dar problemas. (Pois pode dar mesmo! A medida que um projeto cresce, fica mais difícil identificar a necessidade.. o simples fato de inicializar, ajuda a minimizar erros.) Então, vejamos o código: Vejam como é belo (espero que eu não erre em algo, rs): observem lá que a variável aux pode receber uma atribuição de valor dentro de uma estrutura de seleção (se), certo? E que, por sua vez, também está dentro de uma estrutura de repetição (para), ou seja: Em relação à variável em si, não tem problema algum, mas o que poderia dar errado? Ali na última linha do código está utilizando essa tal variável aux, e, caso ocorra o que citei (só ter valores menores ou igual a 0), essa variável aux estaria com o seu valor inicial, que é o 0, lembram?... Logo, seria o mesmo que fazer: ordinal[0] Sacam? A necessidade de inicializar ou não, nesse caso, está apenas na possibilidade de está com um valor válido para o contexto, ou seja, não haveria erro de sintaxe, apenas erro de lógica. Especificamente para um caso, essa posição não existiria, ocasionando um erro de execução (tentar achar uma posição de vetor que não existe). Eventualmente até poderia existir, por exemplo, passando o vetor para começar do 0. Indo de 0 a 9 (em vez de 1 a 10). Não ocorreria erro algum na execução... só que o resultado ficaria errado. Oh! se digitar só zero, ficaria parcialmente certo!, pois iria informar que o primeiro era o maior . Vejam que estamos ignorando a possibilidade de números maior repetidos!!!! VAMOS MAIS ALÉM: Tecnicamente esse aux := 1 pode não ser necessário mesmo, mas é que existem outros probleminhas que precisariam ser resolvidos lá na lógica... Enunciado: Observem que não tem nada a ver com "informar a posição por extenso ou a posição em ordinal", sacam? Foi um subproblema que foi inserido além do que foi pedido. A minha sugestão seria: primeiro se atentar ao enunciado, depois pensar nas possíveis melhorias ou tentativas de ir além dele. Vejam um trecho do código: Um problema maior aí está nesse balaio de gato de se e não no texto de resultado. Pode funciona assim? Pode, mas no mínimo fica complexo de mais para algo que seria simples. AQUI ABAIXO VOU DEMONSTRAR UMA METODOLOGIA DE COMO IMPLEMENTAR UMA CORREÇÃO/SOLUÇÃO Sobre: Pode ser assim? Pode, mas não seria comum. Poderia até informar para "separar os números por espaços". Aqui em vez de ler todas os valores em uma linha, leria por um laço. Meu código começaria assim: algoritmo "Maior número inteiro" //3) Ler 10 números inteiros, ao final mostrar o número maior. var num, i : inteiro inicio escrevaL("Informe 10 números inteiro") para i de 1 ate 10 faca escreva ("Número ", i:2, ": ") leia(num) fimPara fimAlgoritmo Também escolheria o para, pois temos uma quantidade fixa de repetições. Veja o teste: Para chegar nesse resultado, eu testei alguns vezes e fui ajustando... Para facilitar o processo, tem esse recurso bem bacana: Depois só rodar o código. Lembrar de desativar depois! Tá! Implementei uma estrutura para ler os dados, agora vou implementar mais alguma coisa. Vou lá implementar a verificação do maior. algoritmo "Maior número inteiro" //3) Ler 10 números inteiros, ao final mostrar o número maior. var num, i : inteiro maior : inteiro inicio escrevaL("Informe 10 números inteiro") para i de 1 ate 10 faca escreva ("Número ", i:2, ": ") leia(num) se (num > maior) então maior <- num fimSe fimPara escrevaL() escrevaL("O maior número informado foi o ", maior:1) fimAlgoritmo Acho que cheguei ao fim... Hum! Vamos nos aprofundar... tentei analisar o problema. Venha cá: qual o valor de maior na primeira verificação? Eu não atribui nenhum valor para ele. Testei com números negativos: (deixei três pois testei na mão) Ué? Por que deu 0? Então, já "aprendemos" que o VisualG inicializa as variáveis numéricas com zero, logo, maior vale zero... e, logo, nenhum dos números que informei foi maior que o maior..., logo, continuou com o valor inicial, que é zero! Precisamos resolver esse problema (que uma das ideias de quem propôs o enunciado era justamente se aprofundar um pouco e aprender coisas de um modo geral, inclusive aprender a aprender). Uma alternativa seria inicializar maior com um número baixo. maior <- (-999999) para i de 1 ate 10 faca escreva ("Número ", i:2, ": ") ALEATORIO -100, -1 leia(num) ALEATORIO OFF se (num > maior) então maior <- num fimSe fimPara (propositalmente inseri o ALEATORIO no código... em vez de "para que ser isso?", qual tal pesquisar e descobrir? Saca? Caso ainda tenha dúvidas, só perguntar) Parece que funcionou. Matematicamente eu já sei que vai funcionar com qualquer valor inteiro maior ou igual a -999999. (Ou não?). Se informar um número ainda menor? Esse problema vai continuar existindo... Por isso que vai do contexto. Não precisa ficar sempre perfeito... mas podemos tentar ir cada vez mais se aproximando de algo ideal. Que tal descobrir qual o menor número inteiro do VisualG e usar lá? Outra solução seria inicializar o maior com o primeiro valor. para i de 1 ate 10 faca escreva ("Número ", i:2, ": ") ALEATORIO -100, 100 leia(num) ALEATORIO OFF se (i > 1) então se (num > maior) então maior <- num fimSe senao maior <- num fimSe fimPara Parece que funcionou também. Esse código poderia ser o que eu iria entregar. Agora perceba (feat Prof. Procópio): a forma de "inicializar com o primeiro" poderia ser feita de diversas outras formas também... isso seria um subproblema, ou seja, eu já "imagino que isso funciona", mas qual a melhor forma de implementar? Vai se aprofundando.. ou não... depende..... Agora: de onde tirei que "poderia inicializar com um valor bem baixo" ou "que poderia inicializar com o primeiro". Man, quase certeza que vi isso em algum lugar... arrisco a dizer que mais de 90% da população mundial ocorreu o mesmo. Parece bobo para que já viu, mas é complexo para quem tá cru. O importante é entender qual o raciocínio envolvido. Acho que lembro de ter batido cabeça com meu coloca de faculdade, e ele me deu a resposta. Mas acho que ele me falou que eventualmente viu essas possíveis soluções em algum outro lugar (ou inferi isso). Não vejo problema algum. É normal. Muitas das soluções que damos podem ser baseadas em soluções já tivemos contato ou que adaptamos. O importante assimilar. Solução até aqui: algoritmo "Maior número inteiro" //3) Ler 10 números inteiros, ao final mostrar o número maior. var num, i : inteiro maior : inteiro inicio escrevaL("Informe 10 números inteiro") escrevaL() para i de 1 ate 10 faca escreva ("Número ", i:2, ": ") ALEATORIO -100, 100 leia(num) ALEATORIO OFF se (i > 1) então se (num > maior) então maior <- num fimSe senao maior <- num fimSe fimPara escrevaL() escrevaL("O maior número informado foi o ", maior:1) fimAlgoritmo Vamos dizer que já temos uma solução final. Agora, como treinamento, vou tentar inserir a melhoria para exibir por extenso. Mas observem que isso está um pouco ALÉM do enunciado. Declarei uma variável e coloquei para receber o valor de i. se (i > 1) então se (num > maior) então maior <- num posMaior <- i fimSe senao maior <- num fimSe Só fiz isso... para testar, vejam que dá para ver ali no lado no VisualG. Oh! lá marcando a 4 posição. Versão "final": algoritmo "Maior número inteiro" //3) Ler 10 números inteiros, ao final mostrar o número maior. var num, i : inteiro maior, posMaior : inteiro ordinal : vetor [1..10] de caractere inicio ordinal[ 1] <- "primeira" ordinal[ 2] <- "segunda" ordinal[ 3] <- "terceira" ordinal[ 4] <- "quarta" ordinal[ 5] <- "quinta" ordinal[ 6] <- "sexta" ordinal[ 7] <- "sétima" ordinal[ 8] <- "oitava" ordinal[ 9] <- "nona" ordinal[10] <- "décima" escrevaL("Informe 10 números inteiros") escrevaL() para i de 1 ate 10 faca escreva ("Número ", i:2, ": ") //ALEATORIO -100, 100 leia(num) //ALEATORIO OFF se (i > 1) então se (num > maior) então maior <- num posMaior <- i fimSe senao maior <- num posMaior <- 1 fimSe fimPara escrevaL() escrevaL("O maior número informado foi o ", maior:1) escrevaL("Está na ", ordinal[posMaior], " posição") fimAlgoritmo Adendo 1: Observem que, no VisualG, tecnicamente, para esse código acima, não precisou inicializar a variável posMaior (o mesmo que seria o aux). OU ele vai ficar com o 1, caso o primeiro seja o maior ou se todos os números forem iguais ao primeiro. OU vai ficar com outro valor de posição correspondente ao maior. Sempre vai ser atribuindo um novo valor para ele. Adendo 2: O posMaior só estaria sendo atualizado dentro de um se (o senao também faz parte), correto? Em algumas linguagens de programação, o compilador poderia identificar esse contexto e informar algo como: "ALERTA: a variável posMaior pode não inicializada". Aí buscaríamos reforçar a lógica para ver a necessidade. Teria compilador que não deixar rodar até que "corrija". Adendo 3: Quando o programa cria uma variável, ele meio que apenas "reserva uma espaço de memória e prepara para que aquele espaço armazene dados do tipo dessa variável" no computador. Daí, o que estiver lá nesse pedaço de memória, é o que fica na variável. Isso é um conceito de estrutura de dados. As memórias sempre estão com dados lá. Dizer que "está livre" ou "ocupado" está na abstração, ou seja, o espaço livre seria "aquele que pode ser substituído e utilizável". Por isso que é "um padrão inicializar a variável", ou seja, dar um valor inicial logo quando cria ou em algum momento oportuno, como no exemplo do @devair1010. Aqui no VisualG isso não é necessário, pois o VisualG já inicializa para as variáveis globais... acho isso errado pois tira a oportunidade de já entender isso desde o início... sei lá. Por fim, só demonstrar que o VisualG inicializa sozinho: No C (corrijam-me se estiver engano), as variáveis NÃO são inicializadas. Ficam com o "lixo" que está lá na memória. Meio que pode ocorrer de ficar com o mesmo valor de uma execução anterior do mesmo programa, por exemplo. Pode dá rúim!!!

O primeiro número é o 1001 (já que é "maior que 1000"), mas algoritmo aí está começando com número 1002 (uma inconformidade). Basta inicializar o num com 1000 mesmo. Só para ficar claro: e se 1001 dividido por 11 desse resto 5? Para exemplificar, troque o 11 por 12 e teste inicializando com 1001 e com 1000 e vejam o que acontece.

No VisualG, "toda divisão de inteiros gera um real", ou seja, o inteiro 1, dividido pelo inteiro 2, gera o real 0.5. Isso para quaisquer números reais (com exceções do 0 no denominador, é claro)... por isso que uma variável que receberia um resultado de uma divisão de inteiros precisa ser real, mesma que a divisão seja exata. (Não pode ser inteiro.) Abaixo tem como seria uma divisão padrão: No VisualG, esse quociente é sempre real. Mas aqui a divisão é como no dia a dia, não fica limitada à definição... se a divisão não é exata, vai continuar dividindo até o resto ficar zero ou até um limite pré-programado. Exemplo: Ou: Nesse exemplo teriam infinitas casas decimais, mas meio que ao chegar na 12ª casa decimal, o cálculo termina. Isso seria um "parâmetro" da linguagem*. Em relação ao operadores aritméticos % ou mod (que são a mesma coisa no VisualG), eles apenas podem ser utilizados com inteiros mesmo e o resultado também sempre será um inteiro, pois o resto de uma divisão é sempre inteiro. 1 mod 2 (ou 1 % 2) = 1, pois, como já citato, 1/2 dá 0, e tem resto 1. Esse "1" é o que esse operador buscou. No exemplo da imagem mais acima, 17 mod 2 resulta em 1 também. @Eli Almeidaa, nesse caso, você estava pesquisando sobre o mod e % e surgiu uma dúvida sobre a divisão, certo?. Está tudo bem! Mas como percebeu que tinha algo estranho ou que não estava dominando do assunto, expandiria a pesquisa, ou seja, pesquisaria uma pouco sobre "como funciona uma divisão"... poderia ter chegado aos tais "elementos da divisão" que citei. Por aí vai. Só para exemplificar, o operador \ que retorna apenas o quociente. Vejam:

Sim... basta implementar o que falta. Ali estaria só um esboço inicial. Sobre a organização geral, uma dica seria criar uma procedimento especificamente para imprimir uma loja: procedimento imprimir_loja() inicio escreval("Código --: ", cad_shopping[a, 0]) escreval("Nome ----: ", cad_shopping[a, 1]) escreval("Área ----: ", cad_shopping[a, 2]) escreval("Tipo ----: ", cad_shopping[a, 3]) fimProcedimento Assim, quando precisar, só invocar o procedimento. Exemplo: procedimento listagem_lojas() inicio escreval(" Está no listagem loja") escreval() para a de 0 ate contador-1 faca escreval(a, "ª Loja ") imprimir_loja() escreval() fimpara escreval() escreval("Total De Lojas Cadastradas -> ", contador:1) escreval escreval(" Tecle Enter") leia(resp) fimProcedimento Vantagens: a impressão fica padronizada e quando precisar ajustar alguma coisa, só precisaria ajustar uma vez lá no procedimento (em vez de ajustar um a um em cada vez que tem essa estrutura). O mesmo princípio daria para fazer para "aguardar o ENTER". procedimento aguardar_enter() inicio escreval() escreval(" Tecle Enter") leia(resp) fimProcedimento

O "i" é uma variável do tipo inteiro, assim como é o "n". Só verificar lá parte de cima do código. No contexto do algoritmo, funciona como um contador. Utilizamos essa letra "i" apenas por convenção, ou seja, como se fosse um padrão no mundo da programação... Quando tem dois contadores, utilizamos "i" e "j"... depois o "k"... por aí vai. Veja, poderia ser qualquer nome válido (existe uma regra, por exemplo, não pode começar com um número) para uma variável... Veja o exemplo abaixo: algoritmo "Ímpares 2" var n, cidade : inteiro Inicio cidade <- 1 //inicializando o contador escreva ("Digite um número: ") leia(n) repita se cidade % 2 = 1 então // esse simbolo % eh igual a esse "mod" escreval(cidade) fimse cidade <- cidade + 1 //atualiza o contator para o próximo número ate cidade > n //condição de parada fimAlgoritmo Vai funcionar exatamente como o código postado anteriormente... Por que é recomendável seguir um padrão? Fazemos isso par dar uma "semântica" melhor ao código. Veja como "cidade" não tem nada a ver com o contexto. Tende a confundir quem for ler o código... inclusive o próprio autor!!! "Oxe! tá escrito cidade, mas tá recebendo um número... que bizarro". Uma outra nomenclatura que ficaria boa: var n, contador : inteiro É muito comum também utilizar "cont". Entende? Ao ter contato com essa variável, de cara saberia para quê ele deve (deveria) servir, ou seja, "a nomenclatura estaria com uma boa semântica". É também preciso exercitar a abstração... Tentar entender o que cada coisa é... ao seguir um padrão, utilizando o "i", já facilita o processo, pois essa tal de convenção já ajuda a entender que isso aquilo um contador. Dá menos trabalho para pensar. Quando mais padrões seguirmos, menos complicado tende a ficar. Aí entramos na questão da lógica do problema. No código acima já dei a dica. Resumidamente estamos querendo verificar se os números de 1 a n são ímpares ou não. Daí, idealizou que o número atual a ser verificado começaria com 1, por isso utilizou o "<-" para atribuir o valor a variável, ou seja, quando ele for verificado lá pela primeira vez, vai verificar se 1 é ímpar. Já o" i <- i+1" está atribuindo o valor da própria variável acrescido de 1, logo, o seu sucessor. Como começou com 1, ao chegar nessa linha vai passar a ser 2. Na próxima 3, depois 4 etc. Por fim, o ate "i > n" é que, ao "i" ter um valor maior que "n", significa que já deve parar o laço de repetição.. é a "condição de parada". Tudo isso é "uma abstração". Nós humanos entendemos que está se verificando a paridade de vários números... Mas para o computador, são apenas sequência de passos. O que significa "i % 2 = 1"? Para que serve a % no VisualG? Quando não souber, pesquisa no Google... Verás que % é um dos Operadores Aritméticos do VisualG, ele retorna o "resto da divisão do valor que está no lado esquerdo, pelo valor que está no lado direito".... e o MOD? É exatamente a mesma coisa. i % 2 = 1 É o mesmo que: i MOD 2 = 1 Beleza? Agora perceba, o que você estaria comparado? i %MOD 2 = 1 e i %MOD 2 <> 1 Logo, o quê o primeiro representa e o segundo representa? Tá, no primeiro, "quando um número inteiro é dividido por 2 e dá resto 1 significa o quê?". Significa que é ímpar! (sugiro pesquisar mais a fundo o que é um número ímpar e o que é um número par. Entender matematicamente. Isso é importante! O algoritmo é só um meio de entramos em temas... no caso "o quê é paridade") No segundo, "quando um número inteiro é dividido por 2 e dá resto DIFERENTE 0, significa o quê?". Significa que ele NÃO é par. Quando não é par é o quê? É ímpar, logo... as duas fórmulas são equivalentes... em outras palavras: são a mesma coisa! Adendo: perceba também que ao dividir um inteiro por 2, necessariamente OU vai dar resto 0 OU vai dar resto 1. Sempre!!! Logo, quando é "<> 0" é automaticamente "= 1". Concebe abstrair sobre isso? Adendo 2: veja como poderia ficar utilizar o para, no lugar do repita. algoritmo "Ímpares 2" var n, i : inteiro inicio escreva ("Digite um número: ") leia(n) para i de 1 ate n faca se (i % 2 = 1) então escreval(i) fimse fimPara fimAlgoritmo Observe como fica "mais simples", pois nesse caso, como tem um contador, o comando para se encaixa como uma luva. Nesse caso, o "de" ali no para serve para dar o valor inicial da variável que está servindo para controlar o laço e o "ate" define qual é o limite. Se pararmos para exercitar a abstração, poderíamos concluir que o para seria uma "especialização do enquanto ou do repita", ou seja, feito para "simplificar determinado tipo de laços de repetições". Já o repita e o enquanto são mais genéricos. Tudo que se faz com o para, dá para fazer com repita e enquanto, mas no VisualG, nem tudo que faz com repita ou enquanto dá para fazer com para... pois este último é "mais específico", saca? Portando, tem menos flexibilidade (Exemplo: no VisualG não meio que não dá par afazer um loop infinito com para).

@nathalia.prado, dá uma olhada nesse tópico: Adiantar mais um detalhezinho: Se tem "divisão" no meio, a variável não pode ser inteiro. Dar primeiro uma olhada lá no tópico (sobre o possível problema com o escolha) e testa teu código. Para resolver essa questão do tipo numérico, mude para real, mas sugiro testa primeiro antes de ajustar!!! (para entender o erro).

@juniorbenz7, imaginando que está digitando respostas corretas, como citado pelo@Midori, deve ser algum problema com a versão do teu VisualG. Atualizei lá o tópico, veja lá. Eu imagino que está utilizando a versão 3.0.7.0, pois como no teu código tem uns ";" ali na declaração de variáveis, na verão 2.5 nem iria rodar. Independente da versão, remova esses ";", pois não fazem parte da sintaxe do VisualG. Além disso, verificar os outros detalhes citados pelo @devair1010.

Complementando um pouco: Existem basicamente três versões: a 2.5, a 3.0.6.5 e a 3.0.7.0. A versão que seria a mais recomendada é a 3.0.6.5. Caso já estejam utilizando ela, sugeriria baixar novamente. (Fazer o backup da pasta original.) Fontes para versão 3.0.6.5 https://sourceforge.net/projects/visualg30/files/VISUALG3_REV60.rar/download http://visualg3.com.br/download/2090/ Fontes para versão 3.0.7.0 https://sourceforge.net/projects/visualg30/files/visualg3.0.7.rar/download http://visualg3.com.br/download/2086/ Fonte para versão 2.5 https://dicasdeprogramacao.com.br/download/visualg-2-5.zip Caso queiram teimar em continuar usando a versão 3.0.7.0, teriam 3 formas para contornar: 1) digitando a resposta toda em maiúsculo; 2) transformando a resposta em maiúsculo; 3) comparando com o valor maiúsculo. Exemplo para o 1: Exemplo para o 2: ou no caso específico para os times: escreva ("Entre com o nome de um time de futebol: ") leia(time) time <- Maiusc(time) Ou seja: a própria variável passariaa ficar com o correspondente todo em maiúsculo. Se digitasse "BoTaFogo", ficaria "BOTAFOGO". Exemplo para o 3: escolha Maiusc(time) caso "Flamengo", "Fluminense", "Vasco", "Botafogo" escreval ("É um time carioca.") caso "São Paulo", "Palmeiras", "Santos", "Corínthians" escreval ("É um time paulista.") outroCaso escreval ("É de outro estado.") fimEscolha Dessa forma, o conteúdo da variável fica intacto. Permanecendo da mesma forma que foi digitado. *** Caso opção tem as suas vantagens e desvantagens.. Adendo 1: lembrando que se utilizar a 3.0.6.5 não precisaria nada disso. Adendo 2: por que ocorre esse erro na versão 3.0.7.0? Então, entendo que ao comparar os caracteres, o VisualG meio pega uma cópia em maiúsculo tanto da variável que está no escolha, tanto as opções que estão em cada caso. Daí, por algum motivo, essa versão 3.0.7.0 não está fazendo isso para a variável, ou por erro, ou porque esqueceram . Como maiúsculo e minúsculo são tecnicamente coisas diferentes (as letras possuem código diferentes), as palavras não combinam. Adendo 3: para ser mais didático, entendo que o VisualG não deveria fazer nada disso de comparar em maiúsculo, ou seja, só deveria ser igual quando fosse digitado exatamente igual. Seria mais natural e prático entender que "Botafogo" é realmente diferente de "botafogo" ou "BOTAFOGO".

VisualG 3.0.6.5 Link direto: http://visualg3.com.br/download/2090/

Corrigido a citação... Valeu!

Ué, é em Portugol ou em Inglêsol? Brincadeiras à parte, muito provavelmente seria "área (real)". Dúvida: vai implementar em qual ferramenta? Seria no VisualG, Portugol Studio, qual? Pois cada "programa" pode ter uma sintaxe diferente. Poste o que já conseguiu fazer e qual parte está com dúvidas.

Para evitar confusão na interpretação (pois acho que o resultado ao rodar seja eventualmente o mesmo). Seria bom separar cada conjunto de possibilidade. se ((sexo="masculino") E (altura<=1.70) E (peso<=93)) OU ((sexo="feminino") E (altura<= 1.65) E (peso<= 70)) então Dessa forma não "misturando" o último parâmetro do primeiro caso, com o primeiro do segundo caso.

Perfeito. A diferença é que no primeiro tem o returno (ida e volta). @Beatriz Dorin, por favor, posta o enunciado da questão para contextualiza o código.

Uma sugestão inicial é pesquisar. Exempo: https://www.google.com/search?q=copia+visualg Sim. É preciso seguir as regras. No caso, seria seguir a sintaxe da linguagem. Cada se tem um fimSe correspondente. A posição dos fimSe ficará de acordo também com a lógica do código. Veja: se (opcao = 1) então //[1] se ((copia(sexo, 1, 1) = "m") e (altura <= 1.70) e (peso <= 83)) então //[2] escrevaL(" Adicionado à equipe 1 com sucesso") senao escrevaL(" Você não está dentro dos critérios para entrar na equipe 1") fimSe //final do segundo se senao se (opcao = 2) então //[3] se ((copia(sexo, 1, 1) = "f") e (altura <= 1.65) e (peso <= 70)) então //[4] escrevaL(" adicionado à equipe 2 com sucesso") senao escrevaL(" Você não está dentro dos critérios para entrar na equipe 2") fimSe //final do quarto se fimSe //final do terceiro se fimSe //final do primeiro se Para demonstrar, isolei o primeiro se/senao. se (opcao = 1) então //[1] senao fimSe //final do primeiro se O segundo se está dentro do primeiro se. O terceiro se está dentro do senão desse primeiro se. E o quarto se está dentro do terceiro. Tem que ir treinando. Experimente reescrever o código acima IMPORTANTE: Para postar um código no Fórum, utilize o botão CODE. PS: ao pressionar Ctrl+G, o VisualG tenta dar um força na identação.

Diz aí o que não deu certo. Vou chutar que seja porque eu acho que esqueci de indicar onde declara os procedimentos e funções... Basicamente inserir acima do inicio. Exemplo: ... pagmto : inteiro juros : real procedimento aguardarUmEnter() inicio escreva ("Pressione ENTER para voltar ao menu principal") leia(confirmacao) fimProcedimento funcao mesPorExtenso(numMes : inteiro) : caractere inicio escolha numMes caso 1 retorne "Janeiro" caso 2 retorne "Fevereiro" caso 3 retorne "Março" caso 4 retorne "Abril" caso 5 retorne "Maio" caso 6 retorne "Junho" caso 7 retorne "Julho" caso 8 retorne "Agosto" caso 9 retorne "Setembro" caso 10 retorne "Outubro" caso 11 retorne "Novembro" caso 12 retorne "Dezembro" fimEscolha fimFuncao inicio ... escrevaL("Mês: ", mesPorExtenso(2), "":10, "Ano: ", ano:1) aguardarUmEnter() ... O VisualG vai executando os comando da esquerda para direita, de cima para baixo. Ele meio que ler toda uma linha e executa o que ela entendeu. Para os procedimentos (como o aguardarUmEnter()), ao ser chamado, o VisualG vai "deslocar a ordem de execução" lá para onde está declarado o procedimento, e vai executando tudo que está lá, como se fosse um "subprograma". Ao terminar, volta para a linha onde foi invocada e continua o processo. Para o caso de funções, é bem semelhante, apenas o que muda é que a função seria um procedimento que ao mesmo tempo retorna um valor nela mesma. Só muda isso. Ao tentar executar essa linha onde está o mesPorExtenso(2), o VisualG primeiro vai lá onde está a função... vai executar linha por linha lá, vai encontrar a opção 2 e vai retornar um valor na função. Daí, vai imprimir o texto "Mês: Fevereiro", pois vai utilizar o valor que foi retornado pela função. Função seria como uma "variável", só que o conteúdo é retornando por ela mesma (lá do "subprograma" que foi definido). Adendo: ao ter contato com uma 9dade, se for do interesse, dá uma pesquisada no google.. Por exemplo: "como utilizar procedimentos no VisualG". E se joga!

Nesse caso, não. O problema estaria na base do esboço que postei que foi "idealizado" apenas para uma opção: Ou seja: eu não tinha já pensado em como ficaria ao adicionar opção 2. Isso não foi especificamente proposital, mas é didático. Entra nessa questão que citei: Tipo: com uma opção estava ok, mas ao adicionar a segunda opção, essa mensagem ficou estranha. Parei para entender o problema que tá dando agora e entendi que essa mensagem só deveria aparecer se fosse pressionado a opção 1. Daí tenta achar uma medida de contorno, que poderia ser simplesmente remover essa mensagem, ou deixar ela apenas para quando selecionar a opção 1. Exemplo: se (opcao = 1) então se ((copia(sexo, 1, 1) = "m") e (altura <= 1.70) e (peso <= 83)) então escrevaL(" Adicionado à equipe 1 com sucesso") senao escrevaL(" Você não está dentro dos critérios para entrar na equipe 1") fimSe senao se (opcao = 2) então se ((copia(sexo, 1, 1) = "f") e (altura <= 1.65) e (peso <= 70)) então escrevaL(" adicionado à equipe 2 com sucesso") senao escrevaL(" Você não está dentro dos critérios para entrar na equipe 2") fimSe fimSe fimSe ADENDO 1: sempre mantenha o código identado. Nesse código acima já temos uma certa alta complexidade, onde temos um se/senao dentro de cada opção outro se/senao. Tente entender esse mesmo código sem identar: se (opcao = 1) então se ((copia(sexo, 1, 1) = "m") e (altura <= 1.70) e (peso <= 83)) então escrevaL(" Adicionado à equipe 1 com sucesso") senao escrevaL(" Você não está dentro dos critérios para entrar na equipe 1") fimSe senao se (opcao = 2) então se ((copia(sexo, 1, 1 = "f") e (altura <= 1.65) e (peso <= 70)) então escrevaL(" adicionado à equipe 2 com sucesso") senao escrevaL(" Você não está dentro dos critérios para entrar na equipe 2") fimSe fimSe fimSe ADENDO 2: para opção 3, só seguir a mesma linha de raciocínio: se (opcao = 1) então senao se (opcao = 2) então senao se (opcao = 3) então fimSe fimSe fimSe

Resumindo: Assim como usou ' ' para especificar que é caractere na primeira linha, faltou fazer o mesmo para segunda. O "=", significaria "atribuir o valor da direita na variável da esquerda". É um comando de atribuição. O "==", significaria "o valor da esquerda é igual ao valor da direita?". É um operador relacional (retorna VERDADEIRO ou FALSO). Logo, seria: se (j1 == 'a') { No VisualG o comando de atribuição seria "<-" ou ":=". Já para comparar, seria "=". Um só!

@Reinaldo_Lopes, uns detalhes... se atentando apenas no código original... Segue: Não existe float no VisualG, mas sim o real. Se está invocando um método cadastrar_loja(), deve exisitr um método com o mesmo nome. Ou muda o nome do procedimento para cadastrar_loja(), ou invoca como tá: cadastro(). Dica: a medica que for implementando, já vá testando. Não tente fazer tudo de uma vez. Por exemplo, se a tela de cadastro (que está antes) não estaria rodando, como iria já implementar uma consulta? Em relação ao código do @devair1010, sugeriria um ajuste na nomenclaturas da variável. Por exemplo: Como visto no restando do código, essa matriz não é só para armazenar nomes... Sugeriria algo como: cad_shopping : vetor[1..10, 1..4] de caractere //[posição, (código, nome, área e tipo)] Qualquer coisa é só postar!

O programa já está muito bom! E você pode ir aprimorando alguns detalhes aos poucos! Em relação para qual linguagem transcrever, eu deixo para outros visitantes ajudarem nas sugestões... vou me atentar à lógica e sintaxe do código em si. (A base da lógica meio que pode ser aproveitado lá quando migrar.) Creio que sim! Não deixa de ser um portfólio. Se já mexe com GitHub, melhor ainda! Tenho um bem simples largado por lá. Tá bem simplisão. Se quiser dar uma olhada e/ou contribuir. https://github.com/SimonViegas/CodesForumClubeDoHardware/tree/master/VisualG Alguns pontos em relação ao código: 1# Sobre o uso do comando fimAlgoritmo O comando fimAlgoritmo não pode ser utilizado com essa finalidade. Esse código nem era para rodar!!! Roda porque o VisualG não compila e o interpretador é problemático. Num código, só pode ter um fimAlgoritmo, que seria o último comando lá do algoritmo. Até para corroborar que é um erro, até o Ctrl+G (para identar) bagunça o código. Um exemplo de ajustes: enquanto (operacao < 9) faca . . . se (operacao = 9) então escreval("Logout feito com sucesso!") escreval() fimSe fimEnquanto fimAlgoritmo Adendo: no Pascal, pai do VisualG, tem o exit e o halt, mas no VisualG não existe um equivalente. Já vi até vídeos (aulas profissionais, inclusive) sugerindo utilizar como você fez, mas, pelo menos eu, entendo que é um erro! (Estou aberto para discussão.) 2# Estruturação do menu Aqui existe dois pontos centrais: 2.1 Não utilização de uma opção para ser especificamente o menu principal. (Não ter isso de "Operação 1".) 2.2 Uso de estrutura de seleção que evite verificações desnecessárias. (Utilizar uma cadeia de se/senão, ou, simplesmente utilizar um escolha. Em detrimento de ter um monte de se isolados.) Eu ia destrinchar cada uma das opções, mas eu sou muito prolixo.. Desisti. kkkkkkk Vou exemplificar na prática o problema! Eu entrei no Saldo, daí pressionei 3. Foi direto pro Saque (???). Vê? Por que isso ocorre? Pois TODA VEZ que uma opção é escolhida, todas as outras verificações se é ou não a escolhida é verificada... ou seja: se pressionar 4, vai verificar se é 2, depois se é 3, depois se é 4, como é 4, vai entrar na estrutura de seleção, vai fazer o que tem que fazer, mas depois vai continuar verificando se é 5, se é 6, se é 7........ isso TODA VEZ. Independe do valor escolhido. Com se/senão ou escolha, para quando acha. Não sei se isso era proposital... seria possível, mas do jeito que está ficou estranho. É mais comum simplesmente voltar para o menu principal sempre. (Num sistema mais sofisticado, no sentido de uma tentativa de mais adaptabilidade de uso no dia-a-dia, poderia ir implementando essas funcionalidades. Mas não acho o momento!) Exemplo de base de código utilizando escolha: algoritmo "Caixa Eletrônico v1.01" const SALJUROS = 0.013 var profissao : caractere salario : real senha : caractere operacao : inteiro saldo : real saque : real deposito : real transferencia : real agencia : inteiro conta : inteiro cpf : real confirmacao : inteiro emprestimo : real emprestimo1 : real parcela : inteiro menu : inteiro mes : inteiro mesExtenso : caractere ano : inteiro pagmtoEmp : inteiro acao : inteiro pagmto : inteiro juros : real inicio mes <- 2 ano <- 2023 se MES = 2 então mesExtenso <- "Fevereiro" fimSe escreva("Qual o seu salário?:") leia(salario) enquanto (operacao <> 9) faca limpaTela() escrevaL("Bem vindo, Sr. Tiago") //vírgula antes do vocativo escrevaL() escrevaL("Mês: ", mesExtenso, "":10, "Ano: ", ano:1) escrevaL() escrevaL() escrevaL("Qual operação o senhor deseja realizar?:") escrevaL() escrevaL("2 - Saldo") escrevaL("3 - Saque") escrevaL("4 - Depósito") escrevaL("5 - Transferência") escrevaL("6 - Empréstimo") escrevaL("7 - Investismento") escrevaL() escrevaL("8 - Avançar um mês") escrevaL() escrevaL("9 - SAIR") escreva ("==> ") leia(operacao) limpaTela() escrevaL("Mês: ", mes:1) escrevaL() escrevaL() escolha operacao caso 2 escrevaL("Saldo: R$ ", saldo:1:2) escrevaL() escrevaL() escrevaL() escrevaL() escreva ("Pressione ENTER para voltar ao menu principal") leia(confirmacao) caso 3 escrevaL("Qual valor o senhor deseja sacar?") escreva ("R$") leia(saque) se (saque <= saldo) então limpatela escrevaL("Valor a ser sacado: R$ ", saque:1:2) escrevaL() escrevaL("Deseja continuar? (1 - Sim; 2 - Não)") escrevaL() leia(confirmacao) se (confirmacao = 1) então limpaTela() escrevaL("Saque realizado com sucesso!") escrevaL() escrevaL("Valor sacado: R$ ", saque:1:2) saldo := saldo-saque escrevaL() escrevaL() escrevaL() escrevaL() senao escrevaL("Operação cancelada") escreva ("Pressione ENTER para voltar ao menu principal") leia(confirmacao) fimSe senao escrevaL() escrevaL("Saldo insuficiente!") escrevaL() escrevaL() escrevaL() escrevaL("Operação cancelada") escreva ("Pressione ENTER para voltar ao menu principal") leia(confirmacao) fimSe caso 4 caso 5 fimEscolha fimEnquanto fimAlgoritmo PS: o conceito de "procedimentos" e "funcoes" é bem simples no VisualG. Se já quiser entrar (lá ele) nesse mundo. Exemplos: Para aguardar um ENTER. procedimento aguardarUmEnter() inicio escreva ("Pressione ENTER para voltar ao menu principal") leia(confirmacao) fimProcedimento Aí, toda vez que chamar esse procedimento, vão ser executados o que estiver dentro dele. Daí usa onde quiser. Exemplo: caso 2 escrevaL("Saldo: R$ ", saldo:1:2) escrevaL() escrevaL() escrevaL() escrevaL() aguardarUmEnter() É basicamente isso! Meio que "dar um nome a um conjunto de comando e em algum momento invocar pelo nome escolhido". Exemplo para traduzir o mês. Aqui só muda que a própria função retorna algo nela mesma (olha o tipo ali caractere), e nesse exemplo também está recebendo um parâmetro (o uso dos colchetes e a declaração do parâmetro dentro deles): funcao mesPorExtenso(numMes : inteiro) : caractere inicio escolha numMes caso 1 retorne "Janeiro" caso 2 retorne "Fevereiro" caso 3 retorne "Março" caso 4 retorne "Abril" caso 5 retorne "Maio" caso 6 retorne "Junho" caso 7 retorne "Julho" caso 8 retorne "Agosto" caso 9 retorne "Setembro" caso 10 retorne "Outubro" caso 11 retorne "Novembro" caso 12 retorne "Dezembro" fimEscolha fimFuncao Única diferença entre procedimento e função, é que função retorna algo em si mesma. Em outra linguagem mais populares... tudo é "funcao". E quando não retorna algo em si mesmo, define, por exemplo, com o "retorno void" ("vazio"). Exemplo do uso acima: escrevaL("Mês: ", mesPorExtenso(2), "":10, "Ano: ", ano:1) Vai retornar o valor que foi usando no retorne. (Que no caso o correspondente ao 2, que foi o valor passado por parâmetro ao ser invocado dentro do procedimento escrevaL().). Por aí vai.

Adendo inicial: desculpe se estou prolixo de mais, mas a ideia é tentar analisar ponto a ponto alguns detalhes que acho importante. Vou dividir em partes. PARTE 1 Já tá explicado no "adendo" lá na postagem. Veja: No VisualG você utiliza se quiser. Em alguns linguagens famosas, são obrigatórias (faz parte da sintaxe do comando). Eu prefiro utilizar (manter o padrão mais comum, já que "no dia a dia de programador" meio que vai precisar usar mesmo)... já, por exemplo, o @devair1010, prefere sem no VisualG, assim como você fez.. . Seria uma questão de gosto. Ambas as formas eu entendo que estão perfeitamente corretas! Tanto faz! Só para deixar claro: Forma que você utilizou: se x > 10 então escrevaL("X é maior que 10") fimSe Forma que eu gosto e sugiro: se (x > 10) então escrevaL("X é maior que 10") fimSe Qual o certo? Ambas! Tanto faz. PARTE 2 Que massa! Mas será que já está toda certinha? Não estou dizendo que precisa ficar perfeita, mas você tratou dessa questão que cito abaixo? Então, você pulou isso! (Ou me ignorou). Segue trecho do teu código atual: Experimente digitar uma nota 6.7 e uma nota 3.2 e veja o que acontece. Não vai (não deve) exibir nada!, pois não estão em faixa alguma! Está certo o comportamento que ocorre? Resumindo: corrija isso. Inclusive eu também já deu uma solução. Está lá na minha resposta anterior. Aqui entra naquela questão lá de conjuntos. De intervalos abertos e intervalos fechados. Veja: Aqui está pegando "até o 7, com este incluso". Daí é fechado. No próximo, precisaria então pegar no 7 para baixo, ou seja, aberto. Ao juntar uma com a outra, toda a faixa (entre o 6 e 7, inclusos) estará inclusa. PARTE 3 Perfeito! O que eu gosto de comentar sempre que eu posso: foque no problema, e não na solução. Veja: como alguém vai resolver um problema se sequer sabe do que se trata? Parece óbvio, mas é o que mais ocorre. Então você estaria certíssimo. Precisa entender o que ele quer. Se não entendeu, pare para entender. Ah! Sim, também pode ser interessante tentar fazer alguma coisa... como começar a ler as variáveis, como você fez... mas com a ideia de tentar abrir a mente... se vem algo na cabeça que ajude a enter o que o enunciado quer. Vamos lá. Segue o enunciado: Oras! Se os 2 exercícios anteriores foram sobre "estruturas de seleção para definir algo", por que essa questão seria tão diferente (com menu, possível dupla seleção...)? De cara já me parece incoerente!!! Mas ok! Perceba: Questão 1: ler um dado e categoriza esse dado ("diz qual o conceito"). Questão 2: ler um dado e categoriza esse dado ("diz qual classe de nadador") Questão 3: ler diversos dados e depois ler qual a categoria ("qual equipe vai/pode entrar"). Ué!? Aqui ele quer que o próprio usuário defina? Além disso, essas definições têm inclusas algumas regras! Tá confuso para mim!. Mas vamos lá: Como acho que poderia fazer: Acho que poderia entrar nesse mundo do menu... segue opções que imaginei: OPÇÃO 1 Após ter os dados, exibir um menu com apenas as opções que o usuário pode entrar. Por exemplo: se informar "masculino", "altura de 1.60" e "peso de 70 kg", disponibilizaria as opções 1 e 3 (pois ambas serviriam para esse cara). Aí, se tiver mais de uma opção, o usuário selecionaria. Caso tenha só um, ele já entraria na equipe correspondente. Tipo: se o cara informasse 90 kg, ele só poderia entrar na equipe 3. Talvez esse seja uma pouquinho mais complexo. Mas acho que dá para fazer de boa. OPÇÃO 2 Após ter os dados, exibir um menu para que o usuário selecionar qual equipe entrar, mas daí, verifica se ele tem os critérios necessários ou não. ADENDO: observa que AMBAS AS OPÇÕES estão fugindo do escopo, ou seja, entraria na "liberdade poética". Uma outra boa opção seria "perguntar para quem está propondo o enunciado o que raios ele quer". - Entenda o problema; - Procure seguir o enunciado. É preciso fazer o que se pede. Se você for num restaurante e pedir um hambúrguer, seria coerente o garçom entregar um cachorro quente? Segue um esboço para exemplificar a segunda opção: (peguei emprestado a base do @devair1010) algoritmo "Definição de equipes por critérios pré-definidos" // 3 questão) // Elabore um algoritmo que receba o nome e a idade. Sexo, altura e peso. Após // cadastrar as informações deverá ser exibido um menu para o usuário escolher // em qual equipe ele será adicionado, seguindo a ordem: // Para ser da equipe 1: Sexo masculino, altura até 1,70 e até 80kg // Para ser da equipe 2: Sexo feminino , altura até 1,65 e até 70kg // Para ser da equipe 3: Sexo masculino, altura até 1,70 e até 93kg // ou: Sexo feminino , altura até 1,65 e até 70kg var nome, sexo : caractere idade, opcao : inteiro altura, peso : real inicio escreva (" Informe o seu nome: ") leia(nome) escreva (" Informe a sua idade: ") leia(idade) escreva (" Informe o seu sexo: ") leia(sexo) escreva (" Informe a sua altura: ") leia(altura) escreva (" Informe o seu peso: ") leia(peso) escrevaL() escrevaL("Escolha a equipe que deseja entrar") escrevaL(" Equipe 1: Sexo masculino, altura até 1,70 e até 80kg") escrevaL(" Equipe 2: Sexo feminino , altura até 1,65 e até 70kg") escrevaL(" Equipe 3: Sexo masculino, altura até 1,70 e até 93kg") escrevaL(" ou: Sexo feminino , altura até 1,65 e até 70kg") escreva ("==> ") leia(opcao) escrevaL() se ((opcao = 1) E (sexo = "m") E (altura <= 1.70) E (peso <= 80)) então escrevaL("Usuário ", nome, " adicionado à equipe 1 com sucesso") senao escrevaL(nome, ", você não está dentro dos critérios para entrar na equipe 1") fimSe fimAlgoritmo Com dados propositalmente inválidos para equipe 1: Inválido para o sexo. (obs.: TODOS os critérios precisam ser válidos. Se um não for, já não deve adicionar à equipe.) Com dados propositalmente válidos para equipe 1: Está dentro de todos os critérios. Por aí vai. RESUMINDO: Por favor, poste código completo da questão 1 para revisarmos. Depois, tente fazer o exercício 3 e poste o código completo e onde eventualmente está com dúvidas. No aguardo.

@ricardo_br, que top! Daria para colocar a configuração do tipo no próprio console? Algo como, após arrastar, perguntar o tipo.. aí, digitaria, por exemplo, o "txt" ou o que quiser. @Carlos Daniel Fagneli, da forma que está, poderia deixar uma cópia para cada tipo. Exemplo: GerarListaTXT.bat, GerarListaJPG_e_JPEG.bat (imagino que dá para inserir mais de um tipo de uma vez só) etc.

Seria bom especificar qual o erro, mas vamos lá... Uma dica inicial é: não tente fazer todo o programa de uma vez. Vá fazendo por partes e testando. Vou exemplificar utilizando essa técnica, veja: Montando um esboço inicial: algoritmo "Questão 1" //Escrever um algoritmo que leia uma nota e mostre o conceito equivalente. //Suponha a seguinte tabela de conversão //Nota Conceito //7 a 10 A //4 a 6 B //1 a 3 C //0 REPROVADO var nota : real inicio escreva (" Informe a nota: ") leia(nota) escreval(" Nota informada: ", nota:1:2) fimAlgoritmo Daí testa para ver se está lendo certinho... Teste bem bobo. Só para ir pegando o ritmo mesmo. Adicionando uma verificação: var nota1 : real inicio escreva (" Informe a nota: ") leia(nota1) se (nota1> =7 ou <=10) então escreval (" Conceito A") fimSe fimAlgoritmo Testando: Oras! se está com erro nessa linha, para que raios eu continuaria implementando o resto? Entende? Tenta entender e corrige logo. Tá. Aqui temos vários errinhos. 1. precisa especificar a comparação para cada valor, ou seja, seria algo como: se (nota1 > =7 OU nota1 <= 10) então 2. o operador relacionado é junto, ou seja, ">=". Sem espaço entre eles: se (nota1 >=7 OU nota1 <= 10) então 3. por fim, precisa explicitar a separação das sentenças, no caso, utilizando os "(): se ((nota1 >= 7) OU (nota1 <= 10)) então Adendo: esse par de parênteses externos são facultativos. Eu particularmente prefiro assim. OK! A sintaxe está correta agora, vamos testar a lógica: Opa! 5 não é maior que 7 e menor que 10... tem algo errado aí! Ah! ali não é OU, mas sim E. se ((nota1 >= 7) E (nota1 <= 10)) então Testei com alguns valores, como 5, 7, 9 e 10.. todos deram certo! Pronto. Agora implementa mais alguma coisa. Segue por enquanto onde estaria: algoritmo "Questão 1" //Escrever um algoritmo que leia uma nota e mostre o conceito equivalente. //Suponha a seguinte tabela de conversão //Nota Conceito //7 a 10 A //4 a 6 B //1 a 3 C //0 REPROVADO var nota : real inicio escreva (" Informe a nota: ") leia(nota) se (nota >= 7) E (nota <= 10) então escreval (" Conceito A") senao se ((nota >= 4) E (nota <= 6)) então escreval (" Conceito B") fimSe fimSe fimAlgoritmo Testei com outros diversos valores e passaram de boa... parece tudo certo. Mas ué!? Resolvi testar com 6.5 e não funcionou? Essa nota existe! Deveria dar "Conceito B", mas não deu! Consegue identificar o que está errado? Daí deixo para você parar para corrigir isso e depois implementar o "Conceito C". Dica: você precisa incluir os valores entre 6 e 7, correto?. Logo, poderia utilizar "nota < 7", em vez de "nota <= 6". Percebe a diferença? No aguardo.

Complementado: 1# Sobre inicialização das variáveis Faltou inicializar o TOTMED. Pois pau que dá em Chico dá em Francisco..., ou seja, é necessário manter a coerência no código. Já que iniciou um, teria que inicializar os outros caos semelhantes. Exemplo: TOTMED <- 0.0 Obs.: o VisualG já inicializa as variáveis globais automaticamente, ou seja, o desenvolvedor da "IDE" VisualG já programou o "compilador" para fazer isso por nós. As variáveis numéricas já ficam com "0" ao rodar o programa. Experimente criar um variável e depois já exibir o seu valor na tela. Desta forma, não seria necessário reinicializá-las com 0, certo?... Entretanto, como esse comportamento não é comum em outras linguagens de programação*, não vejo problemas em deixar assim. Seria o que chamaríamos de "boa prática". 2# Sobre cálculos de médias Você está calculando a médias N vezes, mas só precisa calcular uma vez só!!! Não? Logo, o cálculo da média poderia ficar após o fimPara. 3# Sobre os casos Creio que meio que dependeria do enunciado... Mas de um modo geral, o 0 seria nulo E seria múltiplo de 5 ao mesmo tempo, certo? Logo, o código estaria parcialmente correto... Só faltou considerar que o 0 também é par! Daí, uma alternativa seria adicionar a verificação do zero também dentro do se do par, o que me pareceria deixar código redundante; outra poderia simplesmente deixa 3 se separados. Exemplo: se (N = 0) então TOTNUL <- TOTNUL + 1 fimSe se (N % 5 = 0) então TOTDIV <- TOTDIV + 1 fimSe se (N % 2 = 0) então TOTPAR <- TOTPAR + N fimSe Segue uma demonstração de resultado: (deixei com 3 valores para ficar mais simples) PS: lembrando que o 0 é par. Daí, 10 + 0 = 10... Mas ele está sendo somando.