| |
|
|
| |
to: час
(09.08.2012 в 13:27)
|
| | Я делал проще.
Сначала всегда узнавал текущее состояние разделителя. Дальше форматировал все числа от пользователя в соответствии с представлениями системы, дабы получались верные результаты. Далее, нужно при помощи replace менять значение не правильное, на правильное. и затем работать с ним.. 
Можно так, как я:
Option Explicit
Private Sub Command1_Click()
Dim DelimiterCurr As String, DelimiterNotCorrect As String
DelimiterCurr = Right(Left(CSng(1 / 2), 2), 1)
If DelimiterCurr = "." Then DelimiterNotCorrect = "," Else DelimiterNotCorrect = "."
MsgBox "Ok: " & vbTab & DelimiterCurr & vbCrLf & "nOk: " & vbTab & DelimiterNotCorrect
End Sub
|
Можно вовсе при помощи API узнавать..
Если же задача рассматривается с точки хрения Excel, то можно и оттуда считать разделитель верный. | |
| |
| |
| |
|
|
| |
to: Анатолий (Киев)
(09.08.2012 в 15:36)
|
| | спасибо за исчерпывающий ответ на не исчерпывающий вопрос! | |
| |
| |
| |
|
|
| |
to: час
(09.08.2012 в 15:32)
|
| |
как отразится на работе(если они привычно будут ставить запятую) а в системе поменять разделитель
|
Если они нажимают на клавишу "." на числовой клавиатуре, то будет вводиться системный символ, а если на общей клавиатуре, то в ячейке запишется текст, а не число. | |
| |
| |
| |
|
|
| |
to: час
(09.08.2012 в 15:32)
|
| | Более юзерфрендли было бы завести доп. булево поле в базе и ставить признак (запятая или точка) при считывании того, что ввел юзер. После преобразовываешь к формату, который использует база. При выводе данных из базы пользователю на форме опять выставляешь то, что ввел пользователь (на основе данных из базы). | |
| |
| |
| |
|
|
| |
to: час
(09.08.2012 в 13:27)
|
| | Писать код так, чтоб он не зависил от десятичного разделителя (ДР). Собственно ДР вмешивается там, где происходит преобразование число->строка или строка->число. Например дробное число в запросах должно всегда быть с точкой:
n = 12.34
CurrentDB.OpenRecordset("SELECT...WHERE [Поле]=" & n)
Такой код нормально будет работать с ДР="."(точка) и приведет к ошибке при ДР=","(запятая).
CurrentDB.OpenRecordset("SELECT...WHERE [Поле]=" & Str(n))
А этот будет работать в любом случае.
Если поставить там точку, то можно ли продолжать использовать запятую при создании документов Excel и Word.
|
Смотря как создаете. И вообще, уточните вопрос.
На заметку: В настройках Excel можно указать ДР, отличный от системного.
Будут ли эти программы при работе в коде выдавать на гора - неверные расчёты?
|
Про расчёты в Word ничего не скажу, а в Excel если в ячейку внесено число, то в выражениях это будет работать независимо от того, как оно отображается на экране. Тазве что, функция ТЕКСТ() вернет текстовое представление этого числа с учетом ДР. | |
| |
| |
| |
|
|
| |
to: snipe
(09.08.2012 в 14:47)
|
| | простите, вопрос не в этом.
как отразится на работе(если они привычно будут ставить запятую) а в системе поменять разделитель на точку. | |
| |
| |
| |
|
|
| |
to: час
(09.08.2012 в 13:27)
|
| | Менять
запятую на точку где надо (безапелляционно)
Для всех мил не будешь
надо делать как правильно а не как привыкли
(я например долго боролся с датой - как только не вводили в екселе, а сейчас - привыкли)
Хотя если честно то запятая при вводе чисел удобнее | |
| |
| |
| |
|
|
| | Проясните ситуацию с десятичным разделителем в системе Windows.
Я последенее время прошу пользоваться (устанавливать в системе) десятичный разделитель точка.
И соответственно программы делаю с учётом, что на машине в настройках будет стоять - точка.
И предупреждение программа выдаёт поставьте там точку в панели управления языки и рег настройки.
====================================================================================
А тут просьба - не менять там запятую, оставить как есть. Привыкли использовать запятую при заполнении всего, всего.
Если поставить там точку, то можно ли продолжать использовать запятую при создании документов Excel и Word.
Будут ли эти программы при работе в коде выдавать на гора - неверные расчёты?
Как мне лучше поступить.? | |
| |
| |
