Программка xo1.kex (см. аттач). Должна при каждом клике менять курсор.
Под KlbrInWin - работает как задумано, под Qemu курсор меняется, не при клике, а при клике и последующем сдвиге курсора.
---
xo3.kex - после смены курсора програмно сдвигаю его на 1 пиксель в сторону
в Qemu - курсор меняется, но сдвижки не хочется. В KlbrInWin сдвижка происходит не на пиксель, а аж вылетает за пределы формы.
---
xo4.kex - вариант со сдвижкой и возвратом в ту же координату
в Qemu курсор не меняется, опять требуется hexyfz сдвижка, в KlbrInWin дребезг курсора, видимо успевает несколько раз сменить курсор пока нажата кнопка.
xo2.kex - курсоры с полупрозрачностью
В KlbrInWin отображаются нормально, в Qemu мусор. В хелпе написано - "файл курсора должен быть в формате .cur, стандартном для MS Windows", на прозрачность ограничений не накладывается.
Вопросы - кто виноват и что делать работает ли xo1.kex как положено не в эмуляторах, а на реальной системе (сам проверить не могу). Если работает, то есть ли эмулятор в котором тоже работает, чтобы перейти на него с Qemu.
То же самое, касаемо полупрозрачных курсоров из xo2.kex.
Не знаю, соотносятся ли мои вопросы с предыдущими курсорными темами, если надо, то объедините
курсор меняется, не при клике, а при клике и последующем сдвиге курсора.
У меня такая же проблема в fNav. В той теме я писал, что он у меня меняется не сразу, а только если подвигать мышью, поэтому приходится делать это программно.
С прозрачными курсорами тоже проблема.
Spoiler:В VirtualBox работает правильно:
На реальной системе без драйвера — тоже правильно:
Точно, видел. Почему бы пока что не использовать такой подход:
0CodErr wrote:У меня такая же проблема в fNav. В той теме я писал, что он у меня меняется не сразу, а только если подвигать мышью, поэтому приходится делать это программно.
Зачем костыль в программе? В 37.5 должна быть принудительная перерисовка курсора.
Допустим я подозреваю, что в svn\kolibri\kernel\trunk\video\cursors.inc - proc set_cursor или в kernel.asm - app_set_cursor: должно быть воткнуто что-то вроде:
mov [redrawmouse_unconditional], 1
call __sys_draw_pointer
Но я с ядром дела не имел, портить проверять не полезу. А ядерщику имхо несложно поправить, или наоборот опровергнуть меня и указать, что подобной правкой мы затронем 100500 других функций, не учтём over 9000 ситуаций и править надо совсем в другом месте и совершенно не то и т.п.
Я подожду.
lev wrote:Но я с ядром дела не имел, портить проверять не полезу. А ядерщику имхо несложно поправить, или наоборот опровергнуть меня и указать, что подобной правкой мы затронем 100500 других функций, не учтём over 9000 ситуаций и править надо совсем в другом месте и совершенно не то и т.п.
Я подожду.
Ну, жди. У ядерщиков есть и другие более насущные вопросы, и ты не поверишь у них существует даже IRL насущные вопросы.
Leency wrote:Mario_r4
То, что нет времени самая левая отмазка Помог бы человеку, хоть советом.
Для меня что помогать советом, что самому код смотреть одинаково. Лень тут совершенно не при чем - у меня действительно недостаток времени наблюдается.
lev
В таком случае, нужно просто брать и править код. Вначале протестировать у себя на машине, перед заливкой в транк. Если вылезут старые ошибки - это прекрасно, их можно будет исправить. Вылезут новые, тоже можно будет исправить, а ели что откатить изменения.
Вообще исправление багов - это всегда два шага вперёд, один назад. Так что не бойся, фиксь транк, фиксь его полностью.
Попытка правки фукции 37.5
Не нашел wakeup_osloop, поэтому воспользовался первым методом из собственного поста.
Тестировать можно на файликах из данной темы и на BabyPainter