Re[4]: Автоматизация Excel: авт. изм. формата при уст. Formu
От: nETPoBu4  
Дата: 03.10.07 07:44
Оценка:
Здравствуйте, Vi2, Вы писали:

Vi2>Конечно, определяется, но не играет здесь роли. Я просто обратил внимание на то, что строка "01.01.07" в одном случае точно трактуется как дата, т.е. формат даты соответствует строке, в другом — не соответствует. Но если программа позволит себе трактовать разделитель "." как альтернативный, то дата разбирается. Некоторые программы и в этом случае переводят в дату и отображают в формате даты, и тогда видно это преобразование. Например, "01.01.07" == "01/01/07" == "01-01-07".


Vi2>Поэтому я и предположил, что язык запущенных Excel-ей разный. Как что и почему — . Можно запросить в форуме VB/VBA, там лучше знают поведение Excel. Возможно, программы устанавливают формат ячеек или меняют какие-то договоренности по языку.


Язык Excel-ей одинаковый, более того, это один и тот же Excel, на одной и той же машине, в одно и то же время. Интересно, что сформированные разными вариантами программы, документы после открытия ведут себя одинаково при вставки дат и чисел с плавающей запятой ( как вариант Б ). Отличие в поведении — только непосредственно в момент программного вызова присваивания значения ячейки.

На одном сайте про дельфи нашел статью "Особенности работы с русским Excel-ем". Там автор предлагал
>"профиксить" вызов DispCall из модуля ComObj.pas. При вызове Invoke, ему передается LocaleID равный 0 (Language Neutral) ... Если заменить LocaleID на $0409 (US English), то все начинает работать как нужно!
для того, что бы формат чисел можно было задавать английскими символами.

Кажется, у меня похожая ситуация и замена lcid может сработать. Другое дело, что прийдется руками поправить Qt-шную обертку и все LOCALE_USER_DEFAULT переправить на 409. Не очень элегантное решение для того, чтобы поправить поведение одного метода.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.