Всем доброго времени суток, вопрос мой касаеься работы с Grush,
как я понял пакет ToGrush, как раз и предназначен для переноса готого проекта, путем добовления его  в Uses, но у меняв возникло пару проблем:
1) ToGrush местическим образом исчезает из Uses, когда например перемещаю компоненты..
2) в нем идет замена функции MessageBox, на свою, но у меня почему то она отображаеться без "GRush-эффекта", да и еще нельзя ли также отображать как в обычном мессажд боксе иконку сообщения(слева от текста сообщения)

> опять про GRush

Уф… Зачем пугать? :) Вопрос не по GRush, а по ToGrush :)

> grim   (15.09.07 22:17) 
> Всем доброго времени суток, вопрос мой касаеься работы с
> Grush,как я понял пакет ToGrush, как раз и предназначен
> для переноса готого проекта, путем добовления его  в Uses,
>  но у меняв возникло пару проблем:1) ToGrush местическим
> образом исчезает из Uses, когда например перемещаю компоненты.

Добавляйте вызовы своих модулей после (place your units here->). Например, было:


Добавляем свой модуль:


Блок uses пересоздается каждый раз при модификации MCK-проекта, поэтому помещайте ссылки на сторонние модули в конец блока.

Danger ага спачибо, а по поводу MessageBox можете чтонибудь подсказать?!

Danger ага спачибо, а по поводу MessageBox можете чтонибудь подсказать?!

Посмотрите, каким IFDEF эта замена обрамлена, и добавьте соответствующий символ в свойтсва проекта (билд не забудьте).

На счет замены MessageBox. Не знаю, была ли эта проблема еще у кого-то, кроме меня, но при использовании вышеупомянутой замены размер exe-файла увеличивается на ~50 килобайт, и в map-файле появляются упоминания SysUtils, VarUtils и других "тяжеловесных" модулей.

И еще. В модуле ToGrush в 777й строке нужно заменить string на KOLString:



строка 896. Заменить PChar на PKOLChar:

на



строка 992. Дописать вызов
в конец функции OwnerDrawMenuItem, иначе fastmm указывает на утечку памяти.

Спасибо.

еще про Grush
а можно их создавать c windowed = false?

> [7] Barloggg   (09.10.07 14:30)
> а можно их создавать c windowed = false?

Нет. А зачем?

наверное для прикола.
подумал что мое приложение в котором штук пятьсот всяких контролов может воспользоваться фишкой с графическими контролами, и я глобально подставил конструкторы для графических объектов. в результате счетчик объектов GDI с 400 упал до 120. неплохо.
однако это приложение опционально использует Grush. то есть запуск без параметра - Grush с параметром - графические.
разница во времени запуска появилась.

ну вот и логичная мысль, а можно ли? ну нельзя, так нельзя.
кстати подключение графических контролов добавило 6 кб. к уже существующим 577кб... гм.

> [9] Barloggg   (09.10.07 14:40)
> разница во времени запуска появилась.

тоесть? В какую сторону? Неужели с графическими контролами медленнее стало? :)

ну почему же медленнее. как было заявлено, так и работает. запуск быстрее, поотзывчивее. да и объектов меньше. правда вот с прозрачностью лабелов выплыли глюки.

так что с графическими контролами запуск быстрее. две секунды против трех-четырех секунд с Grush.
всякие там onMessage для каждой кнопки мне не нужен.

вот была бы возможность создание части контролов производить после отрисовки формы, это было-бы иногда полезно, но MCK такого и не думает делать.

> [11] Barloggg   (09.10.07 15:03)
> вот была бы возможность создание части контролов производить
> после отрисовки формы, это было-бы иногда полезно, но MCK
> такого и не думает делать.

А у тебя все 400 контроллов на одной форме?

да.
только разложены по куче вкладок.

это генератор карт для игры. там туча всяких движков, ползунков кнопочек, фишечек.

была бы возможность создание части контролов производить после

Для этого могут пригодиться фреймы. Советую.

хм. фреймы.
почему бы и нет?
вкурил пример... неплохо.

спасибо.

правда демка скомпилиться отказалась... :) ну да ничего.

> [5] Vladimir Kladov   (16.09.07 19:54)
> (билд не забудьте).

Да, ребилдол — хорошее лекарство :o)

насчет фреймов...
сделал парочку.

перебросил туда полсотни контролов. простым вырезанием и вставкой.
пару часиков занимался восстановлением слетевших методов, кстати очень интересно потерянных, VCL их потерял, а МСК не совсем :) если так можно выразиться.
пришлось воспользоваться inc файлом для сравнения.

так вот результат... своеобразный.
программа при запуске не создавая фреймы стала занимать на 1мб больше. было 13 стало 14. гм.
а при создании фреймов так и вообще на 3 мб больше чем без фреймов вообще.
это какой-то хитрый план?

кстати время запуска на глазок не изменилось, на пламенном-то проце...

гм. насчет объемов похоже я неправ.
на рабочей машине от intel все работает как должно. и по расходу памяти и по скорости. причем от винды к винде расход памяти изменяется. во дела!

кстати на 64битной винде замечены траблы с грушами выровненными по caTop и NEW_ALIGN, правда данных маловато для однозначной формулировки.

> [18] Barloggg   (15.10.07 10:11)
> кстати на 64битной винде замечены траблы с грушами выровненными
> по caTop и NEW_ALIGN

1) Как может влиять, граши или не граши учавствуют в алгне?
2) Как 64-х битность может влиять на приожение, если оно 32-х битное, и Майкросовт гарантирует его правльную работу? :)