| Вопрос: Влип капитально - Picture1.Width | Добавлено: 01.11.07 22:45 |
Автор вопроса:  Roma
|
| Ответы | Всего ответов: 23 |
|
Номер ответа: 16 Автор ответа:  Roma Вопросов: 3 Ответов: 15 |
Профиль | | #16 | Добавлено: 02.11.07 16:06 |
| При разделении видимой области на ряды или столбцы полностью пропадут все алгоритмы различного перемещения фото и еще появятся пара технических неувязок. Выход один единственный - найти контейнер повместительнее. | ||
|
Номер ответа: 17 Автор ответа:   Администратор ICQ: 278109632 Вопросов: 42 Ответов: 3949 |
Web-сайт: Профиль | | #17 | Добавлено: 02.11.07 19:05 |
| Не думаю, что нет контрола вместительнее. Разве что будешь вручную через CreateWindow создавать окна. и то не уверен. Контрол таких размеров создать нельзя.... | ||
|
Номер ответа: 18 Автор ответа: LamerOnLineICQ: 334781088 Вопросов: 108 Ответов: 2822 |
Профиль | | #18 | Добавлено: 08.11.07 18:30 |
|
То есть аффтаром предлагается держать на контейнере примерно 600 пикчеров при том что за раз видимых из них будет от силы штук 10?
Лыжная смазка тут не поможет... |
||
|
Номер ответа: 19 Автор ответа: RomaВопросов: 3 Ответов: 15 |
Профиль | | #19 | Добавлено: 08.11.07 21:57 |
| Я уже писал выше (Номер ответа: 14) - видимых может быть около 200 pic-ов. И это при моём разрешении экрана 1024 на 768, если у кого стоит больше, то и видимая часть соответственно - больше. А 200 умножаем на 3 = 600 конторолов должны передвинутся на любое малейшее передвижение скрола. Не всякий комп такое потянет. | ||
|
Номер ответа: 20 Автор ответа: HACKERРазработчик Offline Client Вопросов: 236 Ответов: 8362 |
Профиль | | #20 | Добавлено: 08.11.07 23:38 |
Ну пусть на экране 600 пикчеров в контейнере (хотя я плохо себе это представляю). 600 же влазит? И больше влазит.. а вот когда ты уже реально дохрена запихиваешь - тогда проблемы. Вот ты отображай в контейнере только те фотки, которые влазят на экран + ещё чуть-чуть  Когда скролл будет подходить к ещё неподгруженным фоткам - ты их будешь подгружать, но эта неподгруженная область будет ещё за пределами экрана, и процесс подгрузки виден небудет.. а потом уже когда скролл подойдёт этим фоткам - они уже будут давно подгружены...
|
||
|
Номер ответа: 21 Автор ответа: RomaВопросов: 3 Ответов: 15 |
Профиль | | #21 | Добавлено: 09.11.07 00:44 |
|
...хотя я плохо себе это представляю
так представь себе 20 на 10 фоток - вот тебе и будет 200, плюс умножаем на каждые прикрепленные 2 элемента, то и есть в сумме 600 контролов. А выход с дозагрузкой похоже единственный, совпали идеи, я ее уже третий день колупаю, возникли только проблемы со старыми давно отлаженными блоками программы drag&drop и т.д. Спасибо всем, кто отозвался. |
||
|
Номер ответа: 22 Автор ответа: ChampionICQ: 461506481 Вопросов: 38 Ответов: 88 |
Web-сайт: Профиль | | #22 | Добавлено: 12.11.07 14:24 |
|
сталкивался с подобным, когда создавал карту города, ещё чёрт знает когда)
чисто для интереса, когда ты загружаешь всё, сколько оперативки ест ВБ? я тогда использовал LOAD control\unLOAD control, для видимых на экране и невидимых, иначе бейсик умирал после второго запуска При разделении видимой области на ряды или столбцы полностью пропадут все алгоритмы различного перемещения фото
п.с. иногда проще и быстрее написать всё заново, чем ломать голову себе и другим, решением невозможного) в апи GDI такие же ограничения по размерам для графики и если не изменяет память, я тогда перепробовал всё, что было в винде и везде такие ограничения |
||
|
Номер ответа: 23 Автор ответа: RomaВопросов: 3 Ответов: 15 |
Профиль | | #23 | Добавлено: 12.11.07 14:55 |
|
только что проверил оперативку:
при загрузке самой программы - 16мб при загрузке в нее 1210 изображений сжираемая память увеличилась до 22мб, такая маленькая разница обьясняется тем, что загружаемые изображения дублируются, уменьшаются и загружаются только маленькие под актуальный размер (их тоже можно менять) "...п.с. иногда проще и быстрее написать всё заново, чем ломать голову себе и другим, решением невозможного)" согласен, но ТАААААААААКОЙ влом переделывать большой кусок работы ........ 
|
||