Каморка

по воможности на весь рабочий стол, не переключая разрешение экрана?

На этом рисунке -- так как есть:



А на этом -- так, как хотелось бы:



Второй вариант получен снижением разрешающей способности экрана с 1600х1200 до 640х480. Вариант плохой, потому что, для работы с другими приложениями опять надо включать высокое разрешение...

Any idea, как можно обмануть аппликуху и звставить ее работать в отдельньном окне с низким разрешением, в то время как остальной экран для остальных приложений работал бы в высоком?

Типа так:



.

Прикольная задачка. Можно посмотреть что там есть в виндовых API на тему копирования содержимого окна, если destination будет больше source то у тебя растягивание и получится. Это как "лупа" программная работает. Тогда не надо будет отдельного экрана.

Не помню какая это функция, давно было.

Sheen писал(а):Это как "лупа" программная работает. Тогда не надо будет отдельного экрана.

Да, я как раз что-то в этом роде и ищу...

.

А не решить ли проблему другим способом?
http://www.chessbase.com/shop/
http://chessmaster10.ubi.com/us/

Ну это даже совсем не по программерски ... ну ка давай проваливай в Игрульки со своими игрульками.

Вот, похоже нашёл, только проверить надо - http://msdn2.microsoft.com/en-us/library/ms532355.aspx

Интересно, как это будет работать со StretchBlt? То есть, пишем отдельную прогу, которая берёт содержимое окна chess-проги, StrechtBlt его в своё окно, обрабатывает ввод мышки, посылает сообщение обратно в chess-прогу, и ждёт обновления окна chess-проги? Кроме того, НDC имеет смысл только внутри создавшего его процесса (HDC нельзя DuplicateHandle), то есть надо будет хватать НDC экрана. Да и как бы ты передал HDC из chess-проги, да же если б это можно было DuplicateHandle?
Я думаю, проще всего написать прогу, которая будет менять разрешение экрана по нажатию клавиши. Либо попробовать hook chess-прогу и поиграть с WM_CREATE, WM_MOUSEMOVE, WM_PAINT etc. Это возня, конечно, но если chess-прога написана грамотно, то не так уж и много её (возни) будет ...

Stanislav писал(а):А не решить ли проблему другим способом?
http://www.chessbase.com/shop/
http://chessmaster10.ubi.com/us/

Здрасьте вам! Это ж все за деньги. А мой Nagasaki -- даром

.

Azazello писал(а):Интересно, как это будет работать со StretchBlt? То есть, пишем отдельную прогу, которая берёт содержимое окна chess-проги, StrechtBlt его в своё окно, обрабатывает ввод мышки, посылает сообщение обратно в chess-прогу, и ждёт обновления окна chess-проги? Кроме того, НDC имеет смысл только внутри создавшего его процесса (HDC нельзя DuplicateHandle), то есть надо будет хватать НDC экрана. Да и как бы ты передал HDC из chess-проги, да же если б это можно было DuplicateHandle?
Я думаю, проще всего написать прогу, которая будет менять разрешение экрана по нажатию клавиши. Либо попробовать hook chess-прогу и поиграть с WM_CREATE, WM_MOUSEMOVE, WM_PAINT etc. Это возня, конечно, но если chess-прога написана грамотно, то не так уж и много её (возни) будет ...

Делается так:
1. В процесс с приложением внедряется ДЛЛ.
2. Далее изменяем адреса импортируемых функция GetDC и BeginPaint на наши функции.
3. В этих функциях если запрашивает контекст главного окна приложения, даем контекст bitmap'a/metafile'a .
4. Полученный файл (в памяти) растягиваем на нужный размер (раньше StretchBlt работала очень примитивно, так что лучше использовать более сложную аппроксимацию).
5. Полученное изображение выводим на нужное окно.

Aldep, мысль интересная. Правильно ли я понял: через SetWindowsHookEx, CreateRemoteThread->LoadLibrary, или CreateRemoteThread->WriteProcessMemory мы внедряем DLL (или прямо код в случае с WriteProcessMemory) и каким-то образом изменяем адреса GetDC и BeginPaint на наши, причём наши функции работают как hooks. Создаём своё окно из своей thread, и, далее, направляем нужный вывод туда... Звучит заманчиво, не спорю.

Вопросы:
1. Допустим мы нашли адреса GetDC и BeginPaint (user32.dll (?) mapped в одно и то же место). В запущенном процессе мы можем туда записывать? Я не пробовал никогда, какой-нибудь AccessViolation не выскочит?
2. Если мы туда запихнули наши функции, не возникнет ли проблемы с chess-прогой? То есть, наш GetDC должен вызвать нормальный GetDC и передать результат дальше, верно?
3. Не проще ли просто заменить EndPaint - chess-окно уже будет обновлено, и просто перекинуть содержимое в наше окно в этот момент?
4. Что делать с вводом в наше окно? Надо будет писать WndProc для нашего окна, чтобы двигать фигуры, и дублировать все сообщения в chess-прогу. Наверняка, chess-прога флаги выставляет когда фигура выбрана, так что все мышиные сообщения точно надо пересылать.
5. Нельзя ли hook WM_CREATE, WM_PAINT, WM_MOUSEMOVE etc, изменить размеры окна в WM_CREATE и надеяться, что chess-прога нормирует координаты на размеры окна. Кстати, chess-прога может быть нормирует всё на какие-нибудь зашитые константы, было бы ещё проще. Или я бред несу? Я никогда таких сложных hooks не пробовал...

Azazello писал(а):Aldep, мысль интересная. Правильно ли я понял: через SetWindowsHookEx, CreateRemoteThread->LoadLibrary, или CreateRemoteThread->WriteProcessMemory мы внедряем DLL (или прямо код в случае с WriteProcessMemory) и каким-то образом изменяем адреса GetDC и BeginPaint на наши, причём наши функции работают как hooks. Создаём своё окно из своей thread, и, далее, направляем нужный вывод туда... Звучит заманчиво, не спорю.

Вопросы:
1. Допустим мы нашли адреса GetDC и BeginPaint (user32.dll (?) mapped в одно и то же место). В запущенном процессе мы можем туда записывать? Я не пробовал никогда, какой-нибудь AccessViolation не выскочит?
2. Если мы туда запихнули наши функции, не возникнет ли проблемы с chess-прогой? То есть, наш GetDC должен вызвать нормальный GetDC и передать результат дальше, верно?
3. Не проще ли просто заменить EndPaint - chess-окно уже будет обновлено, и просто перекинуть содержимое в наше окно в этот момент?
4. Что делать с вводом в наше окно? Надо будет писать WndProc для нашего окна, чтобы двигать фигуры, и дублировать все сообщения в chess-прогу. Наверняка, chess-прога флаги выставляет когда фигура выбрана, так что все мышиные сообщения точно надо пересылать.
5. Нельзя ли hook WM_CREATE, WM_PAINT, WM_MOUSEMOVE etc, изменить размеры окна в WM_CREATE и надеяться, что chess-прога нормирует координаты на размеры окна. Кстати, chess-прога может быть нормирует всё на какие-нибудь зашитые константы, было бы ещё проще. Или я бред несу? Я никогда таких сложных hooks не пробовал...

1. GDI32. Да, память конечно read-only, но есть VirtualProtect()
2. Если хотим отображать изначальное окно тоже, то тогда да.
3. Тогда уже надо заменять и ReleaseDC тоже. Наверное можно.
4. Да, это я не упомянул, но это-то несложно. Просто все клавиатурные события и маштабированные мышиные пересылаются мелкому окну.
5. А кто его знает, как она нормирует? Скорее всего не на размер окна. Раз окно не позволяет делать себя больше определенного размера, то скорее всего фигуры хранятся как битмэпы и клетки тоже имеют фиксированные размеры под эти битмэпы.

На самом деле можно сделать проще, если предположить, что компьютеры сейчас сильно мощнее, чем те, на которые расчитана программа. Можно просто по таймеру вызывать скажем раз пять в секунду PrintWindow API и перерисовывать большое окно.
Тогда конечно мы можем терять или ухудшить качество анимации, но оно тут неважно.
Тогда не надо никаких хуков, просто пересылать клавиатурные, мышиные и Invalidate сообения изначальному окну.