Erro de multiplicação de preços

[Pablo Polícia]

Ola pessoal, estou criando um sistema de venda de produtos e tenho um problema.

Criei uma edit que armazena o preço 1 e outra edit que armazena o preço 2.

No evento OnExit do preço 1 coloquei assim:

format('%f',[]);
[/CODEBOX]

Isso faz com que toda vez que eu colocar um valor, aparecerá em forma de dinheiro, no caso em reais. Até ahi tudo bem.

O problema é na hora de multiplicar o preço 1 com a outro valor sempre dar erro:

O erro é: R$ 20,00' is not a valid floating point value.

alguém pode ajudar!!

:rolleyes:

Editado Dezembro 14, 2008 por Pablo Polícia

[paulobergo]

Olá.

Você precisa tirar o 'R$' antes de calcular qualquer coisa...

Veja que a mensagem de erro já te diz o que está errado: a identificação da Moeda... pois R$ não é valor...

Eu uso o componente HKComps (HKDBCurrEdit e HKCurrEdit) pois não preciso fazer qualquer conversão... pois o Edit já fornece um valor mesmo e não um texto... outra coisa, ele permite que você até mostre o nome da moeda (o R$) sem que isso interfira no valor...

Creio que existam outros componentes similares...

Agora, em tempo... não é usual colocar R$ nos valores, exceto quanto se usa mais de uma moeda...

Se você pegar uma nota fiscal impressa por uma loja, observe que não vem R$ na frente dos valores... pois todo valor, no Brasil, deve estar em Reais... quando isso não acontece, aí sim você coloca o nome da moeda... US$, índices como UFIR, UFMG, etc... e o R$ ainda polui muito a tela, sobretudo com o alinhamento à direita dos valores. Veja:

R$ 0,99        0,99
     R$ 10,00       10,00
    R$ 988,45      988,45
     R$ 66,45       66,45
    R$ 988,45      988,45
  R$ 1.484,60    1.484,60

Ok?

Bom...

Consulte mais por aí (principalmente legislação e normas técncas para aplicações comerciais)...

Espero ter ajudado...

[Pablo Polícia]

Obrigado paulobergo pelas dicas, mas na verdade há uma variavel para trabalhar com moedas no Delphi. É a Corruency, mais ou menos isso.

alguém sabe como trabalhar com moedas com essa variavel. Por que todos estes valores serão incluidos no banco de dados e eu queria muito que esses valores sejam acompanhados pelo R$.

[Micheus]

No evento OnExit do preço 1 coloquei assim:

format('%f',[]);

Isso faz com que toda vez que eu colocar um valor, aparecerá em forma de dinheiro, no caso em reais. Até ahi tudo bem.

estranha a informação... :huh:

Format("%" [index ":"] ["-"] [width] ["." prec] type)

onde o tipo (type) f corresponde a um número com ponto flutuante, conforme help:

f = Fixed. The argument must be a floating-point value. The value is converted to a string of the form "-ddd.ddd...". The resulting string starts with a minus sign if the number is negative

E a função tem por objetivo retornar uma string correspondente ao número passado como parâmetro.

Por que todos estes valores serão incluidos no banco de dados e eu queria muito que esses valores sejam acompanhados pelo R$.

Em teoria, você deve ter definido estes campos, na sua tabela, como sendo do tipo CURRENCY. Sendo assim, este campo é numérico e o R$ não será gravado com ele. Mostrar o R$ é apenas uma questão visual, onde você deverá formatar o valor de modo a usar a informação de moeda.

Infelizmente, a função CurrToStr não inclui a string da moeda no resultado, sequer o separador de milhar - então, tem que ser na mão mesmo.

Para o processo inverso, é como o colega paulobergo, já lhe sugeriu: retire a informação de moeda e então o texto restante poderá ser convertido para número e gravado no banco.

Abraços

[Pablo Polícia]

Estou trabalhando com o Banco de Dados Paradox, o campo dos preços estão no tipo $(Money) e toda vez que eu coloco o valor aparece automaticamente o R$.

Por exemplo:

Campo 1 - armazena o preço 1

Campo 2 - armazena o preço 2.

Campo 3 - armazena o resultado da multiplicação do campo 1(preço1) e campo 2(preço2).

No campo do preço 3 eu poderia colocar o resultado com o R$ sendo que nos outros campos são valores normais sem R$?

[paulobergo]

Olá...

Veja bem... você precisa aprender a lidar com os campos e com as variáveis... o fato do campo ser do tipo Money, apenas indica que, na apresentação dos seus valores, o nome da moeda (definido nas configurações regionais do Windows) irá aparecer... mas o campo continua sendo numérico... e, assim, não aceitará R$ nem o separador de milhar.

Veja:

1) Criando uma tabela com campos "money"

create table 'meuteste.db'
(
idmeuteste autoinc,
valorunitario money,ç.ol,mjljkiooohyouioiii
quantidade numeric(7,3),
valortotal money
);

0 rows were affected

2) Inserindo um registro.

insert into 'meuteste.db'
(valorunitario, quantidade, valortotal)
values
(1.50, 3, 1.5*3);

1 row were affected

3) Visualizando os registros da tabela.

select idmeuteste, valorunitario, quantidade, valortotal
from 'meuteste.db';

+------------+---------------+------------+------------+
| idmeuteste | valorunitario | quantidade | valortotal |
+------------+---------------+------------+------------+
|          1 |       R$ 1,50 |          3 |    R$ 4,50 |
+------------+---------------+------------+------------+

4) Tentando inserir um registro com R$...

insert into 'meuteste.db'
(valorunitario, quantidade, valortotal)
values
(R$ 1.50, 3, R$ 1.5*3);

* Invalid use of keyword. Token: 1.50, Line Number 4

insert into 'meuteste.db'
(valorunitario, quantidade, valortotal)
values
('R$ 1.50', 3, 'R$ 1.5'*3);

* Type mismatch in expression.

5) Tentando inserir um registro com valores contendo milhar+decimal

insert into 'meuteste.db'
(valorunitario, quantidade, valortotal)
values
(1,250.00, 1, 1,250.00 * 1);

Invalid parameter.

Ah... e o campo subtotal, visto acima na tabela, é redundante e não devia ser criado, já que será o resultado da multiplicação dos outros dois campos... então, seria criado apenas na aplicação, com campo "calculado", quando necessário...

Em tempo (aí é uma opinião)... não uso tabelas Paradox há mais de cinco anos... considero até Paradox muitissimo confiável SE todo o acesso aos dados, inclusão, alteração e exclusão for por TQuery (SQL)... usar TTable, para mim, é um desastre... bem... mas aí é só a minha opinião e, atualmente, fico com o MySQL 5.027 ou maior...

Ok?