svd,
Не очень понял логику построения загрузки (без потоков и т.д.) просто логику программы.
1. У тебя есть 2 интерфейса: старый и новый. Их загрузка обеспечена наличием флага в ini-файле.
2. Тогда ты вроде как должен следовать логике и загружать либо старый, либо новый интерфейс, но не 2 сразу.
3. Если человек захотел переключиться в другой интерфейс (для чего это?), то ты выгружаешь текущий и загружаешь другой.
4. Действительно загрузка конфигурации - это секунды. Ты должен загрузить меню, но не данные. Данные нужно грузить потом, когда пользователь выберет, что он хочет.
5. Если ты грузишь, например, какие-то состояния, статистику, то сделай выставку данных с обновлением на сервере через N-минут и в зависимости от готовности данных перегружай ее на клиент в сжатом виде (диаграммы, групповая инфо), в онлине свести большие объемы данных проблематично и долго.
6. Я просто желаю тебе задуматься над построением логики, а потом уже прибегнуть к потокам.
Разумеется я не описывал детали, которые многим абсолютно не интересны, ненужны, мешают понимать логику того что требуется и правильно сформировать вопрос.
1. Совершенно верно.
2. Имено так. Форма для тач-скрина использвется операторами по месту, занимает весь экран и совершенна бесполезна, когда процессом начинают управлять удаленно - тогда и переключают на старую компактную форму.
3. Допустим текнику, пришедшему на обследование системы нужно видеть все прогрммы управления (в зависимости от конфигурации их может быть от 4х до 7ми). Я невыгружаю "новый нитерфейс", я просто переключаю видимость форм. Меню грузится на этапе запуска, потому как конфигурация в процессе работы не должна меняться. Данные тоже разные есть. Загрузка идет от разных источников с разными "накладными документами": вот эту инфу и нужно загружать во время старта- какие накладные документы активны для какго робота и какие источники загрузки привязаны к каким накладным. В тач-форме правда есть отличие - устройства загрузки имеют приоритеты.
4. Меню грузится автоматически. Но фреймы привязанные к меню сами по себе могут иметь процесс инициализации, связанный с чтением данных из базы. Пример: есть дверь для загрузки. На ней полки. Вдоль каждой полки идет лента ЛЕД-диодов. Вот задача опросом базы связать количество дверей конкретного робота (от желания клиента или факторов помещения могут меняться) с количеством полок в двери. Да еще ЛЕД управляется через DMX-512 интерфейс и получается один сегмент ленты ложится на 3 полки. Когда это нужно вычислять? Логичнее что при начальной загрузке. И таких нюансов море, под каждую конфигурацию.
5. Разумеется все, о чем ты пишешь так и сделано- графики и таблицы отдельно от котлет в загрузке явно не участвуют. В тач версии даже рассово правильней все копазывается - датасеты открываются и делают фетч только в момент, когда нажат пункт меню. Да и то, где требуется отображать в графике или гриде. А чаще всего исполюзуется асинхронный доступ через thread порции данных - нужно пользователю еще, тогда следующая порция и т.д., и т.п.
6. Цель этого топика и была задуматься над построением логики загрузки. Ведь загрузка подобных процессов в линейных режимах приводит к тормозам. И вопрос был о том, кто какие методы использует при загрузке. Судя по посыпавшемуся флэйму ничего нового в этом направлении нет. Но спасибо YuRock, а точнее Дмитрию Сибирякову - ткул носом в документацию, где точно описано то, что нужно. В первом изменении на одной заведомо "долгогрузимой" конфигурации, без оптимизаций запросов удалось сократить загрузку на 25 секунд. Не все, конечно, так гладко, но покрайней мере можно показать прототип и сформировать требование, в каком направление нужно менять процесс инициализации приложения.
