Summary: | Сообщения об ошибках в графику | ||
---|---|---|---|
Product: | WINE@Etersoft | Reporter: | Vitaly Lipatov <lav> |
Component: | Интеграция в хост-систему | Assignee: | Илья Шпигорь <shpigor> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | minor | ||
Priority: | P4 | CC: | amorozov, baraka, kondratyuk, shpigor, vostok |
Version: | 1.0.11 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: | |||
Заявки RT: | Связано с: | ||
Дата напоминания: | |||
Bug Depends on: | 4260 | ||
Bug Blocks: | 1982, 4284 | ||
Attachments: | Попытка добавления MessageBox |
Description
Vitaly Lipatov
2008-06-29 03:31:19 MSD
Created attachment 524 [details]
Попытка добавления MessageBox
В этом месте user32.dll не подгружается. Возможно, что единственное решение - внешняя программа.
Просто так подгрузить GUI к консольке, похоже, невозможно. Имеет смысл писать утилиту. только стоит определиться с функциональностью - это будет узкоспециализированный хак для местного пользования или нечто большее? (In reply to comment #1) > Created an attachment (id=524) [details] > Попытка добавления MessageBox > > В этом месте user32.dll не подгружается. > Возможно, что единственное решение - > внешняя программа. > Может быть, если уже подгрузился kernel32.dll, подгрузить user32.dll с помощью LoadLibraryA , а затем его выгрузить.. Второй вариант - использовать для GUI функции winex11.drv (In reply to comment #3) > Второй вариант - использовать для GUI > функции winex11.drv > Ошибся - навряд ли сработает, т.к. грузится после user32.dll и юзает его функции. (In reply to comment #2) > Просто так подгрузить GUI к консольке, > похоже, невозможно. > Имеет смысл писать утилиту. только стоит > определиться с функциональностью - это > будет узкоспециализированный хак для > местного пользования или нечто большее? Я думал о программе, которая будет выводить через MessageBox передаваемые ей аргументы, с тем исключением, что форматная строка (собственно текст сообщения) будет браться из ресурсов программы по передаваемому коду (чтобы была возможность перевода сообщений на другие языки. Надо просто попробовать. может быть стоит написать dll предоставляющую интерфейс для вывода любых сообщений (заранее собранных в некотором ресурсе и выбираемых по передаваемому коду ошибки/сообщения) в GDI, чтобы его можно было использовать не только для вызова из консоли посредством скрипта, но и использовать в "нормальных" приложениях. а для скрипта написать миниатюрное приложение, которое используя передаваемые ей скриптом аргументы будет лишь вызывать диалог из dll-ки, а весь функционал будет заложен в dll. к тому же для того чтобы можно было использовать одни и те же коды ошибок для разных модулей (соответственно разные сообщения) или с разными языками, можно ресурсы (таблицы строк) прикручивать к разным dll, и явно загружать нужную выбирая по имени модуля, откуда идет вызов диалога. т.е. если вызов откуда-нибудь из-вне приеделов вайн, схема такая: модуль -> скрипт -> миниприложение (находящееся где-нить в /dosdevices) -> dll-ка с диалогом + dll-ка с нужными строками если из "нормального" вайносвского приложения, схема такая: модуль -> dll-ка с диалогом + dll-ка с нужными строками (In reply to comment #6) > может быть стоит написать dll > предоставляющую интерфейс для вывода > любых сообщений (заранее собранных в > некотором ресурсе и выбираемых по > передаваемому коду ошибки/сообщения) в GDI, > чтобы его можно было использовать не > только для вызова из консоли посредством > скрипта, но и использовать в "нормальных" Про скрипт это была начальная условность. На самом деле нужно просто иметь возможность вызывать эту программу оттуда, где нет доступа к графике, но есть возможность выполнить программу. То есть для скрипта уже не нужно. > к тому же для того чтобы можно было > использовать одни и те же коды ошибок для > разных модулей (соответственно разные > сообщения) или с разными языками, можно > ресурсы (таблицы строк) прикручивать к > разным dll, и явно загружать нужную выбирая > по имени модуля, откуда идет вызов диалога. Ну это развитие... > т.е. если вызов откуда-нибудь из-вне > приеделов вайн, схема такая: > модуль -> скрипт -> миниприложение > (находящееся где-нить в /dosdevices) -> dll-ка с > диалогом + dll-ка с нужными строками Ну идея хорошая, просто я сбил своим упоминанием скрипта. > если из "нормального" вайносвского > приложения, схема такая: > модуль -> dll-ка с диалогом + dll-ка с нужными > строками Ну вроде как в таком случае можно и из программы вызвать MessageBox, и ничего дополнительно не требуется. Да, программу будем делать отдельно и в закрытую часть. Сейчас 4 кандидата в сообщения: - Нет такой программы - Запуск не с диска Wine - Работа с сетевого ресурса без модуля CIFS от Etersoft - Превышено ограничение на количество пользователей (4) для версии Network Lite *** Bug 3593 has been marked as a duplicate of this bug. *** Патч на багу #3593 есть рассылке. Он выводит сообщения в случаях: - Нет такой программы - Запуск не с диска Wine Нужна проверка на случаи: - Работа с сетевого ресурса без модуля CIFS от Etersoft - Превышено ограничение на количество пользователей (4) для версии Network Lite Это должна определять закрытая часть? Так как мы решили, писать на чистых Иксах программу, выводящую сообщение? Судя по всему, надо использовать нечто типа Xdialog / zenity / gdialog, но не напрямую, а через обвязку на shell, сваливаясь на xmessage, если не найдено ничего. Потому что задача частая - выводить сообщение. Осталось решить, что делать с локализацией. (In reply to comment #10) > Так как мы решили, писать на чистых Иксах > программу, выводящую сообщение? В случае запуска на неизвестном wine диске подойдёт и etermsg. Разработали программу eterx11msg в рамках 4260. Является аналогом xmessage, по сути. |