| Autor |
Mensagem |
|
|
Acho que vocês me entenderam mal. Eu não estou defendendo os trocadores, pelo contrário. Nada pessoal, nem estou defendendo a demissão em massa, mas as empresas de ônibus vão invertis em tecnologia e além de arcar com os custos de implantação vão continuar pagando os mesmos salários. A culpa não é da empresa nem muito menos da tecnologia, o problema é que o estado não é capaz (não é criado para tal) de recolocar os que vão ser mandados embora. Isso não é um fenômeno brasileiro. Outro dia eu assisti ao folme "Roger & Me" do Michael Moore, falando de quando a GM fechou 11 (eu acho) fábricas na cidade natal dele (Flint) para abrir unidades no México. A culpa é da GM? Claro que não. Ela está jogando de acordo com as regras. Como obrigar uma empresa privada a manter empregos X ou Y. A diferença é no nos EUA o sistema econômico chega perto de funcionar. Já aqui no Brasil... aposto como a conclusão dessa história vai ser alguns políticos e pseudo-sindicalistas mantendo TODOS os empregos e as catracas eletrônicas. Quem vai bancar isso? A empresa? Claro que não, pois senão ela teria prejuízo, obviamente que o populismo aqui no Rio vai converter essa "boa ação" da empresa em subsídio ou abatimento de imposto.
Logo quem paga por isso são todos aqueles que pagam imposto. Tratar o sintoma e não a causa é uma coisa estúpida. A tecnologia sempre traz benefícios.
|
 |
|
|
|
Pelo que você falou parece que o usuário digita o login do banco direto na conexão. Você poderia conectar seu programa com um login/senha com permissão máxima e implementar um controle paralelo de usuários. Desta forma inclusive você tem muito mais possibilidades para permissões e coisas assim. Usando o login do banco você defina as permissões que todo banco implementa (insert, update, delete,grant etc..). Uma das vantagens é que você não precisa saber qual erro voltou, porque na verdade você nem deixa ele acontecer. Você testa se o login existe, testa se a senha está correta, tudo separadamente, assim sabe exatamente o que está errado.
|
|
|
|
Esta sintaxe é de liguagens que implementam "propriedades" onde text não seria um método e sim uma propriedade. Você digita ojbeto.text, mas na verdade está acessando objeto.getText. Da mesma forma poderia ser objeto.text = "texto", na verdade seria objeto.setText("texto"), nestes casos os gets e sets são privados e o acesso é feito pelo nome da propriedade. O java não implementa este tipo de propriedade como é feito no Delphi (acho que o C# tb tem). O comum realmente é criar getText e setText públicos e text privado.
Aliás gostaria de saber o porquê desta ausência de propriedades...
|
|
|
|
louds wrote:
O problema é que esse brinquedinho vai fechar com um MONTE de postos de trabalho. Vc não vai precisar mais passar as compras pelo caixa do supermercado, basta passar pelo leitor e pagar.
Esta é uma outra discussão. Postos serão fechados e outros abertos. No início da revolução industrial os trabalhadores quebravam máquinas para não perder o emprego, Se eles tivessem sido vitoriosos (ideologicamente ou pela força) não estaríamos discutindo neste fórum. Ele nem existiria. Essa questão da perda de postos de trabalho não pode ser barreira para novas tecnologias! Se as pessoas ficam sem emprego é porque não há ação do estado para recolocá-las além da própria falta de empregos normal.
Aqui no Rio já estão começamndo a instalar roletas eletrônicas nos ônibus. O que vocês acham que vai acontecer com os trocadores?
|
|
|
|
Esta é a implementação do método forClass:
O throws no cabeçalho te obriga a tratar ou a passar adiante (acima) o tratamento.
|
|
|
|
Pessoal,
Concordo com o Bruno, às vezes a melhor crítica é impedir a digitação em si e não validar um monte de campos todos errados. Em algumas janelas é melhor validar campo a campo. É o modo "janela" de validar um formulário ao contrário do modo "form" que é usado na internet. Numa janela tem-se muito mais controle sobre os eventos e este controle deve ser aproveitado. Outro dia pus um post sobre JTextFieldNumérico justamente com isso em mente. Se um campo é inteiro a caixa de texto não deve deixar o usuário digitar nehum valor inválido pra começar, e não deixar o infeliz digitar um monte de besteira e depois tratar em um botão ou evento. Até porque mais tarde ainda será necessário determinar quem está com conteúdo irregular e dar foco neste controle, pelo menos isso seria o certo.
Aproveitando o tema não descobri como saber qual é o controle com foco num determinado momento. tentei o código abaixo mas não funcionou.
Eu queria testar o valor de um JTextField antes de sair dele. Se tiver algo errado quero interromper a saída, mas se o controle que ganhar foco for um botão tipo "Cancelar" a saída é permitida. Acho que foi sobre isso que o Bruno estava falando.
Abraços...
|
|
|
|
Não sei se você já pôs, mas esse código
deveria estar parecido com isso:
ou bota throws no cabeçalho do método.
|
|
|
|
É, mas meu monitor é de 15''. Aliás uma coisa que gostei no Eclipse é que podendo rearrumar o workbench dá prá usar em 800x600.
E quanto ao micro, a placa de vídeo on-board rouba um bocado de memória. Ter 128MB e ver o win2000 dizer que está usando 230MB significa que ele tá fazendo swap sem parar. O HD roda direto. Já com 196MB não é tão ruim. Só o win2000+placa de vídeo leva 102MB!!! 
De qualquer forma, postei esta informação porque em listas anteriores o pessoal tava recomendando até 512MB, já é demais.
|
|
|
|
Pessoal,
Outro dia eu vi uma pergunta sobre qual seria uma configuração mínima para rodar o eclipse aqui no fórum. Pensando nisso, resolvi documentar a minha experiência com esta ferramenta no meu computador. Até há alguns minutos atrás eu tinha um Athlon 1.1GHz com 128MB de RAM, como vocês já devem imaginar o Eclipse e tudo mais junto com ele rodava muito lentamente. Hoje coloquei mais 256MB de RAM e o resultado foi o seguinte:
![]() http://www.geocities.com/siviotti/configuracaoEclipse.jpg " border="0" />
1. Rodando o Eclipse 2.1.2, editando uma classe JFrame no VE (o que mais me fazia sofrer), com o help aberto além de um internet Explorer, o Windows 2000 registrou uso de memória de aproximadamente 250 MB, portanto um pouco abaixo de 256MB. No tópico discutido aqui no GUJ disse-se que era necessário 512MB.
2. O processador Athlon 1.1 deu pequenos picos de 100% de uso, portanto, é recomendado pouca coisa mais rápido, mas 1.1GHz para mim está bom.
Conclusão: Considerando que a minha placa mãe tem vídeo on-board (roubando 16MB) um computador de +- 1Ghz com 256MB de memória RAM é uma boa configuração para se trabalhar com eclise (nestas condições). Mais tarde vou testar Tomcat, etc, mas não deve ter grande impacto.
Um abraço a todos...
|
|
|
|
|
Onde você está setando a dialetc (1 ou 3)?
|
|
|
|
Não sei se foi nisso que você pensou, mas..
isto imprime o conteúdo de autoexec.bat para a impressora padrao (PRN)
|
|
|
|
No jogo normal não dá pra fazer mais do 323.5.
|
|
|
|
Para um grupo de trabalhadores esta é uma realidade, com certeza. Mas, pense bem; como um gerente, diretor, e qualquer outro em cargo de chefia e/ou administração pode ser um especialista? Nestes casos tem ocorrido exatamente o contrário: tem que aprender um pouco de tudo! A informática não me deixa mentir. Um indivíduo de uma carreira não técnica não tem o direito de não saber informática, mesmo não tendo nada a ver com ele.
Não estou discordando do artigo, só acho que dependendo do setor para onde se olhe a realidade é diferente. Se não me engano, a própria Veja, publicou há tempos atrás uma matéria sobre os profissionais do futuro. Tinha coisas como Médico/Tecnologo e outras profissões que juntavam conhecimento de várias áreas.
Dá pra ver que a coisa não é bem assim.
|
|
|
|
Ok, o assunto clareou bastante.
Mas o DAO deve ser genérico ou não?
ou
|
|
|
|
Cara,
eu também procurei um bocado sobre isto, mas nada de definitivo.
1. Talvez exista um parâmetro do acrobat (/p /h etc) para direcionar a impressora, mas eu não conheço.
2. Se for win 95/98 você pode editar o win.ini e alterar a impressora padrão pelo código.
3. No NT/2000/XP, não sei, mas acho que dá prá fazer pelo registro, já que é a mesma idéia do win.ini.
4. Pelo DOS daria para redirecionar mas, ai não é o Acrobat que vai imprimir e sai tudo errado!
5. Não achei uma classe java que recupera alista de impressoras do sistema, talvez por ai tenha uma forma de setar a padrão.
Se achar como resolver respondo...
|
|
|
|