Первое, что приходит в голову - в структуру GLO:DM пишеться больше данных, чем ее размер.
В результате этого перезаписываются и переменные, которые непосредственно идут после этой структуры.
Кстати 1: каким размером инициализируется поле DEVMODE.Size?
Кстати 2: поле DisplayFlags имеет тип LONG.
Кстати 3: описание структуры DEVMODE - неполное - там еще есть несколько полей.
=============================
С уважением,
Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
вот кусок из проги в том порядке как идет определение
Код: Выделить всё
program
...
DEVMODE GROUP,TYPE ------------> шаблонная
DeviceName BYTE,DIM(32)
SpecVersion short
DriverVersion short
Size short
DriverExtra short
Fields ulong
Orientation short
PaperSize short
PaperLength short
PaperWidth short
Scale short
Copies short
DefaultSource short
PrintQuality short
Color short
Duplex short
YResolution short
TTOption short
Collate short
FormName BYTE,DIM(32)
LogPixels short
BitsPerPel long
PelsWidth long
PelsHeight long
DisplayFlags short
END
MAP
....
GLO:UseId BYTE ----------> моя переменная
SOLDisplayQ QUEUE,PRE(GDQ) ---------- шаблонная
Desc STRING(30)
Height LONG
Width LONG
BitsPerPel BYTE
DMode LONG
OK BYTE
END
SilentRunning BYTE(0)
GLO:DM Group(DevMode),pre(GDM)
END
DisplayFrequency long
Glo:NeedToResetResolution BYTE
Glo:OrigDisplayWidth LONG
Glo:OrigDisplayHeight LONG
Glo:OrigDisplayBPP LONG
DisplayQ Queue,pre(DQ)
Desc String(30)
DM Group(DevMode)
end
ok byte
END
определение этой структуры GLO:DM идет ПОСЛЕ моей переменной
поиск инициализации DEVMODE.Size ничего не дал, видимо...
это работа шаблона
Hello Олег,
эксперимент показал, что вставка "буферной переменной" после моей такого же размера (byte) предохраняет ее от изменений:( теперь меняется уже буферная, где-то видимо действительно наезжают данные этой структуры на мои...знать бы что еще может изменяться по ходу дела в моих переменных...где-то ошибка в определении этой структуры?
--
Best regards,
olga
Если умеешь пользоваться Клашиным отладчиком, то можешь посмотреть порядок расположения глобальных данных в реальной памяти - компилятор НЕ ВСЕГДА располагает их в том порядке, как они обьявлены в коде - особенно касается структурных переменных типа GROUP/CLASS/QUEUE/FILE/VIEW.
Или можешь поступить еще проще - после старта программы выведи с помощью MESSAGE адреса и РЕАЛЬНЫЕ размеры всех своих глобальных переменных - сразу и определишь, кто конкретно стоит ПЕРЕД и ПОСЛЕ "проблемной" переменной.
Только после этого можно будет сказать что-то более конкретное.
Кстати, я очевидно пропустил, но - какая версия Клариона?
Дело в том, что в C61 расположение переменных и их инициализация несколько другие чем в предыдущих версиях - таким образом SV пытаются минимизировать время инициализации блока трейдовых переменных при открытии нового потока.
=============================
С уважением,
Олег А. Руденко
версия клары 5.5 с 8 -мым патчем
Олег, спасибо за помощь!
И еще один нюанс вылез - не знаю связан ли с этим или нет...
Этот шаблон при входе проверяет разрешение экрана и меняет его , если надо и при выходе восстанавлмвает, если надо. Так вот когда я принудительно , для тестирования, выставила разрешение , которое надо изменить ну, скажем 640х480, погоняла прогу - все нормально, меняется и восстанавлмвается. Выхожу из проги, ставлю опять свое разрешение, работаю дальше, не с этой прогой, выключаю комп нормальным образом, а утром при включении - опять грузится разрешение 640х480! и кроме того 256 цветов, вместо 32 бит.
т.к. это уже было не один раз есть подозрение, что некорректно восстанавливается разрешение в проге (changedisplaysetting(режим,0)), может это связано с неполным определением той структуры, а почему вы так решили, что оно неполное?
--
Best regards,
olga
(Добавление)
Незная, что именно делает этот шаблон, трудно что-то предполагать.
Я не использую подобные методы - зачем? - пусть юзер сам определяет удобные для себя настройки рабочего стола стандартными средствами.
Но, судя по информации о данной функции из WinAPI, во время этих "игр" происходит запись настроек измененного режима в реестр. Это, кстати, может делать и другая программа:
- твоя прога изменила динамически режим экрана
(динамически - значит не пишет инфу о режиме в реестр)
- во время работы системы в этом измененном режиме кто-то производит обновление реестра, считая, например, текущий режим экрана дефолтным.
- после завершения работы твоей проги производится динамическая смена разрешения экрана на первоначальный.
НО! В реестре уже записана другая инфа! Которая, естественно, будет установлена в качестве дефолтной при следующем запуске системы!
Кстати, если уж "по-честному", то следовало-бы в конце проги вызвать вышеназванную функцию вообще без параметром, т.е.:
ChangeDisplaySetting(0,0)
В этом случае восстанавливается именно дефолтный режим экрана из реестра - по крайней мере, сразу будет видно, что что-то изменилось с дефолтными настройками.
А так - при выходе прога ДИНАМИЧЕСКИ как-бы "восстановила" дефолтный режим - а дальше - не наше дело!:))
может это связано с неполным определением той структуры, а почему вы так решили, что оно неполное?
Из описания этой структуры в том-же WinAPI!
Кроме того, что в вашем случае имеем неполную концовку структуры для минимального случая (> ОС W95), так еще нет обязательной концовки для W95-систем. Или Вы не используете программу под W9x?
Ну и, судя по Вашему предыдущему письму, не производится инициализация члена этой структуры, несущего информацию о текущем размере структуры. Для подобных структур в WinAPI это является чуть-ли не обязательным условием гарантированно-правильной обработки таких структур!
Или Вы плохо искали код этой инициализации?
Проще всего - проверить по сгенеренному коду ВСЕХ модулей программы - если такая инициализация производится, то она должна стоять, как минимум, перед первым использованием данной структуры. А по-хорошему, так вообще - перед каждым ее использованием.
=============================
С уважением,
Олег А. Руденко
(Добавление)
Здравсвуйте Олег!
Я не использую подобные методы - зачем? - пусть юзер сам определяет удобные для себя настройки рабочего стола стандартными средствами.
Дело в том, что юзер не умеет этого делать:) и не хочет учиться:) а приходит на чужой комп с этой прогой, а там разрешение 800х600 и не помещается на экране бровз - надо листать - неудобно, вот и взяла чужой шаблон, он вроде простенький - проверяет текущий режим, если он не совпадает с требуемым - меняет его, а по окончании работы - восстанавливает оригинальное и вот после этого начинаются фокусы
- во время работы системы в этом измененном режиме кто-то производит обновление реестра, считая, например, текущий режим экрана дефолтным.
Кто? - я одна
- после завершения работы твоей проги производится динамическая смена разрешения экрана на первоначальный.
схема такова - загрузка системы-1024х768, меняем на 640х480 (в свойствах экрана), запускаю прогу устанавливает - 1024х768, конец проги - 640х480, что-то поделала другое, сменила через свойства экрана на 1024х768, поработала еще с чем-то, выключила комп, включила - 640х480 + 256 цветов
Из описания этой структуры в том-же WinAPI!
Я смотрела описание этой функции в справочнике (печатном) - и не нашла там никакого описания этой структуры, просто сказано, что третий параметр - структура, куда копируются данные, возвращаемые функцией
Кроме того, что в вашем случае имеем неполную концовку структуры для минимального случая (> ОС W95), так еще нет обязательной концовки для W95-систем. Или Вы не используете программу под W9x?
как раз под под нее, хотя тестировала на w2k
Или Вы плохо искали код этой инициализации?
Проще всего - проверить по сгенеренному коду ВСЕХ модулей программы
так и делала - нету ее:(
Спасибо огромное, Олег! Ситуация прояснилась по крайней мере:)
Написал: ClaList(2)
