forum.clarionlife.net

Проблема есть, но совсем в другом месте ...
В неадекватности среды C10 при сборке приложения. Иконки - это то, на чём её поймали.
У меня, например, потеря в "весе" при пересборке некоторых DLL достигает 5%.
И у меня нет уверенности, что C10 "отоптимизировал" только иконки (хотя и это очень неприятный факт).

А делать TMP окно с графикой или вручную добавлять всю графику в ресурсы solution - это уже припарки ...

gopstop2007 писал(а): 22 Декабрь 2017, 21:54 а если иконки в solution explorer-> libraries, objects and Resource files закинуть, какие проблемы?

Именно так. Добавленные в сольюшен ресурсы хранятся в .cwproj. И мистическим образом оттуда исчезают. Повторю Игоря - неважно куда мы ресурсы пихаем, на окно, в Actions броуза, напрямую в сольюшен, при компиляции ресурсы из проекта пропадают.

Стандартно если графика на окне - приложение не соберётся при отсутствии иконки. А вот если она просто упомянута в проекте и выпала из него - вполне может... Другой вариант - иконки кладу как скрытые картинки на экраны, где они используются. Да, ещё была старая ошибка, (не знаю, пофиксили или где... ) - при вызове процедуры из внешнего DLL иконки в дальнейшем ищутся именно там. В некоторых случаях даже добавлял иконки в чужие DLL, чтобы корректно выводилось.

Вторично слетела десятая Винда. Тенденция, однако. Восстанавливаться не хочет никак. Хорошо ещё. что MS помнит мою учётку и не требует движений по активации. Грешу на мать (гигабайт). Но семёрка-то работает на другом диске.
А новостей от SV не будет? Питер отдыхает ?

kreator писал(а): 07 Январь 2018, 19:38 Грешу на мать (гигабайт). Но семёрка-то работает на другом диске.

А производитель для Вашей модели платы выпускает вообще драйвер ?
Или используется "универсальный" драйвер набора микросхем Microsoft Windows 10 ?

А драйвер чего? Винда вроде всё подкачала, все устройства обнаружены. У меня загрузка идёт через новый стандарт UEFI. Что-то здесь не так. В прошлый раз из-за ухода в сон MBR слетел. В этот раз экспериментировал загрузкой с разных дисков. И опять проблемы именно на десятке. И очень похоже на первый случай, хотя немного не так (при загрузке сразу синий экран смерти с сообщением о проблеме в NTFS, в первый раз было сразу сообщение об отсутствии загрузочного сектора). Попробую БИОС обновить. До драйверов дело не доходит. Может Windows 10 вообще не предназначена для работы на десктопе в режиме смены загрузочных дисков?

kreator писал(а): 07 Январь 2018, 21:11Может Windows 10 вообще не предназначена для работы на десктопе в режиме смены загрузочных дисков?

Предназначена, но здесь рекомендуется сначала устанавливать старшую версию (Win10), под ней создать MBR и
только потом устнавливать младшую (Win7). Это вполне логично (Win7 не знает о существовании Win10), но к сожалению,
эволюционно всё происходит зачастую наоборот (к установленной Win7 накатывают Win10).
Из этой же серии - антивирус, который может пытаться отслеживать модификацию MBR.

Не, не так. Я тупо меняю диски, системы на разных дисках. Загрузкой управляет БИОС, точнее говоря. Поэтому грешу на UEFI. В boot-меню БИОСа каждый диск может быть как и в UEFI загрузке так и в обычной SATA. Видимо в зависимости от того как я устанавливал Винду. Семёрка, естественно, не в UEFI. А тут ещё накладывается то, что БИОС держит параметры последней загрузки (например, выход из сна). Всегда так работал. Но раньше UEFI не было, может и проблем не было.

kreator писал(а): 08 Январь 2018, 16:54Я тупо меняю диски, системы на разных дисках. Загрузкой управляет БИОС, точнее говоря.

Да, это вполне понятная схема .... но только в том случае, если при загрузке одной версии Windows, диск с другой не доступен.
А если Вы поочерёдно меняете диск загрузки, делая второй дополнительным - то это постоянно приводит с смене схемы загрузки.
И как я понимаю, после переключения с Win7 на Win10 происходит описываемая проблема ?

Игорь Столяров писал(а): 07 Январь 2018, 21:23 kreator писал(а): ↑
07 Январь 2018, 21:11
Может Windows 10 вообще не предназначена для работы на десктопе в режиме смены загрузочных дисков?

Предназначена, но здесь рекомендуется сначала устанавливать старшую версию (Win10), под ней создать MBR и
только потом устнавливать младшую (Win7). Это вполне логично (Win7 не знает о существовании Win10), но к сожалению,
эволюционно всё происходит зачастую наоборот (к установленной Win7 накатывают Win10).

Игорь Столяров писал(а): 08 Январь 2018, 17:03Да, это вполне понятная схема .... но только в том случае, если при загрузке одной версии Windows, диск с другой не доступен.
А если Вы поочерёдно меняете диск загрузки, делая второй дополнительным - то это постоянно приводит с смене схемы загрузки.

Игорь Столяров верно подметил - данный механизм хорошо работает только при установке новой операционной системы Windows 10 и Windows 7 и выбранной пользователем через BIOS загрузке только когда подключен один физический диск конкретной операционной системы на момент установки или загрузки.

У меня, например, Windows 7 SP1 x64 и Windows 10 1709 x64 (ставилась второй) расположены на разных постоянно подключенных к системной плате дисках без UEFI - выбором управляет загрузчик Windows 10 1709 - причём при необходимости загрузки Windows 7 SP1 после её выбора из меню (от Windows 10 1709) необходима перезагрузка компьютера.

Проблем нет - вот только Windows 7 SP1 x64 запускаю редко (только для тестирования)

Есть желание иметь на одном компьютере все три версии WIndows:
WIndows XP SP3 x32, WIndows 7 SP1 x64, WIndows 10 1709 x64 - сейчас среди пользователей это основные операционные системы семейства Windows - и тестировать релизы собранные в IDE Clarion 6.3 и Clarion 10
желательно на всех этих версиях

А вот с Windows XP SP3 и Windows Server 2003 R2 SP2 c BIOS проблем не было - какой указал в BIOS необходимый загрузочный диск необходимой операционной системой - та и загрузилась.

Может у кого есть опыт эксплуатации на одном и том-же компьютере нескольких активных не виртуальных операционных систем: Windows XP, Windows 7, Windows 10 - расскажите с подробностями

А почему при загрузке одной оси диск с другой должен быть не доступен? Всегда схема работала, ничего нигде не портилось. Похоже всё-таки с UEFI проблемы. Можно предположить что седьмая винда без UEFI портит загрузочный сектор диска с десятой виндой (с UEFI). Но это вообще космос, никак не понять, и не должно так быть. Ладно, аккуратно потестю. Но БИОС переставлять не буду, мать уже старовата, требуется полный апгрейд.

kreator писал(а): 09 Январь 2018, 12:40Можно предположить что седьмая винда без UEFI портит загрузочный сектор диска с десятой виндой (с UEFI).

Именно так и происходит. Только с точки зрения "седьмой винды" она его не портит, а исправляет на корректный.
Сами знаете, куда выслана дорога благими намерениями ...

Это случайно не про Вашего мальчика в газете написали ?

см. https://www.rbc.ru/rbcfreenews/5a54c6b29a79477d98cee4d4

Игорь Столяров писал(а): 09 Январь 2018, 19:19 Это случайно не про Вашего мальчика в газете написали ?

см. https://www.rbc.ru/rbcfreenews/5a54c6b29a79477d98cee4d4

Всё-таки не мой случай. Судя по http://safe.cnews.ru/news/top/2018-01-0 ... meltdown_i, процессоры AMD должны быть очень старыми (10 лет и старше), а у меня сильно поновее .
Сейчас на вновь поставленную десятую Винду накатилось обновление 1709 (возможно, и последнее). Теперь Винда запрашивает пароль на вход два раза. Причём первое приглашение появляется практически мгновенно после включения компа (что очень удивительно), после ввода пароля система секунд пять думает и вновь переходит на картинку. После второго ввода пароля ещё догружается где-то минуту-две (что непозволительно долго для абсолютно чистой оси). Чудеса!

kreator писал(а): 09 Январь 2018, 20:05После второго ввода пароля ещё догружается где-то минуту-две (что непозволительно долго для абсолютно чистой оси). Чудеса!

Это может Defender отрабатывать после наката обновлений. Обычно при загрузке в фоне, но если комп не шустрый,
то это просто приводит к задержке прорисовки рабочего стола.
А запросы паролей - да, выбешивают ! Я их сразу в Win10 отключаю (и при загрузке и при выходе из спящего режима).