-
Notifications
You must be signed in to change notification settings - Fork 0
/
ReadMe.txt
133 lines (108 loc) · 9.35 KB
/
ReadMe.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
The^day^of^DooM
Window Manager
Create date: 09.02.2008
Last Update: 24.07.2008
Full Change: 04.05.2009
Last Update: 05.05.2009
05.05.2009 (23:06 PM)
Покрай програмируемиа контролер отстраних малко проблеми в функцията за създаване на PopUpMenu, по-специално
частта грижеща се за направата на бутоните му + няколко малки проблема наследние от вчера. По-интересни са проените
по самото ДОС приложение на AVR-PLC. За тях в неговият "Read Me" файл.
04.05.2009 (16:59 AM)
Направих една дългоочаквана промяна по кода. По специално "драйвера" на клавиатурата. За разлика от преди
вече отчита натискането на сециален клавиш и го изпраща като съобщение. За момента се засичат стрелките.
Причината за проените е проекта LPC - псто стана нетърпимо натискането на някоии букви да се определя
като специален клавиш и произтичащите от там съобщения.
27.07.2008 (17:18 AM)
Забелязах и отстраних неприятен проблем. Когато даден прозорец е със свален седми бит (0-7; 128) показващ
дали е активен то тогава е възможно да бъде избран прозорец който се намира под него. Страно е, че досега не съм
го забелязъл.
24.07.2008 (21:29 AM)
Отстранен е много неприятен бъг проявил се след последните промени - за да оптимизирам скороста на кода не
съобразих една малка особеност: когато търсим прозорец върху който е кликнато с мишката трябва да спрем цикъла
при първия намерен (в MouseHandler()) - да но заради "оптимизацията" ми пропуснах тази част... И се получаваше
интересни проблеми. Например при избор на рамка и местене на мишката при срещта с друг прозорец то другия бива
избран. Сега вече има цикъл преди този за търсенен на избран прозорец, изпращащ съобщението MSG_MOUSE_CLICK към
всеки прозорец в който не е мишката. Всъщност прави директно извикване на функцията на прозореца за да не се
препълва опашката му със съобщения. Ще трябва да добавя омразното "Not Responding" при достигане на определен брой
съобщения в списъка. Сега се прави проверка за по-вече от едно, което пък е в противоречие с основната концепция,
като е във вида на: if(current->MsgList) return;
23.07.2008 (06:38 PM)
Изчистен е кода грижещ се за PopUpMenu прозорците - преди те се разглеждафа от WindowManager като специален
вид прозорец (чрез бит 5 в flag-а разбираше, че е меню). Целта бе да получава най висок приоритет при обработване на
опашката от съобщения до получаване на MSG_QUIT. Вече това недоразумение е премахнато. На потребителско ниво няма
нижда от преправяне на програмите.
12.07.2008 (12:12 AM)
Функцията _removeFromList, от файла list.h, беше преименувана на removeFromList. Това разбира се изискваше
минимални промени по кода както на приложенията така и на библиотеката. В момента обмислям какви възможности имам за
изчистване дизайна на кода. Не ми харесва как на места на функциите се предава параметър указващ вида на обработвания
обект (бутон, текстово поле и д.р).
10.07.2008 (18:51 AM)
Най-накрая купих мишка. Разбира се кода не тръгна от първия път - бях забравил преминаването от абсолютни миши
кординати към относителни (абс. спрямо прозореца).
07.07.2008 (21:19 AM)
Трън в очите ми беше кода правещ проверка дали даден бутон или входно поле (editbox) е избран с мишката.
Просто функциите isSelectButton и isSelectEditBox бяха почти 100% еднакви, само кастването на обектите бе различно.
И в двете имаше кода вземащ абсолютните кординати на мишката и го превеждащ към относителни спрямо прозореша. После
проверка дали дадения обект попада в тях. Вече е добавена функцията:
HANDLE lpWindowFindSelectObjInList(LPWINDOW lpWindow, LPLIST lpList, UCHAR(*isSelectObj)(LPLIST lpList, UCHAR x, UCHAR y)) // ?
която извиква примерно isSelectButton (но както се вижда с променени параметри и превеща само проврка дали мишката е в
рамките на бутона, като цикъла на обхождане на обектите е изнесен в lpWindowFindSelectObjInList(...). Доста мъгляво
обяснение, важното е, че промените са за добро. Важно уточнение! - поради липса на мишка (от месец е повредена и все
не остава време да купя нова) кода все още не е тестван на 100% !!! Не се налага преправяне на програмите ползващи
прозоречната библиотека.
29.06.2008 (14:25 AM)
От два месеца не бях пипвал кода. Като за начало почти отстраних неприятното премигване /09.02.2008 (18:15)/
- бяй забравил да сменявам номера на активната страница. Почти защото сега пък мишката (курсора) почна да премигва...
27.04.2008 (00:19 PM)
По кода няма абсолютно нищо ново. Просто преди два месеца и 5 дена дори не подозирах колко мога да оплескам
нещата в личен план. Майната му, минало, да видим до къде ще го докарам в бъдеще. Но да оправя първо настоящето ли?...
22.03.2008 (01:34):
И така. Откъде да започна? Ами отначалото. Този месец (март 2008) беше шашав. Много проблеми. Но не това е
важното. След като направих курсовата по ПИК (II част) реших да използвам идеята от FailDialog за прикачане на
функция към бутоните на прозореца при създаване на прозореца. Не, че е нещо ново (преокриване на топлата вода), но
във функцията PopUpMenu се отрази освежаващо. Вече не се налага да ползвам допълнителна променлива с която да се
"орентирам" от къде и кое pop up меню е извикано. Запазих съвместимост със старите програми (с изключение на
извикаването на PopUpMenu).
10.02.2008 (00:48):
Същата процедура и през Borland C++ 4.0. Остава да мине през Open Watcom - там със сигорност ще хване още
съмнитеални парчета код. А и в момента съм изгубил съвместимост с Open Watcom та ще се наложи корекция по кода.
10.02.2008 (00:00):
Пуснах кода като C++ файл през Borland C++ 3.1, за да премахна местата със "съмнително" cast-ване.
09.02.2008 (18:15):
В моемнта файла window.h има вариант при който вместо да се използва междинен буфер в който се "чертаят"
прозорците, се използва смяна на видео страницата. Разбира се втория вариянт е по-бърз но засега не е тестван
напълно, а и в typemain.c заради честото викане на UpdateWindow (уж) ред 0 се изписва с много неприятно премигване.
Или по-скоро се получава при прозорци/програми с много контроли за изчертване при който се с времето за запис
във видео памета е по-голямо от периода на вертикалната синхронизация. За момента не съм сигорен - въпрос е на тестове.
09.02.2008 (17:30):
По-добре късно отколкото никога. Напоследак имам навика да си водя логове на свършената работа.
За жалост текущия е закъснял има-няма само с 3 години. Сега ще се опитам да направя кратка ретроспекция
на работата по Window Manager от самото начало. Мой помощници ще са архивните файлове. Стига общи проказки :)
В началото, някъде към 2004(края)-2005 преглеждах книга (име?) в която се описваше изграждането на
меню-прозоречен потребителски интерфейс в текстов режим. Езика беше Pascal. За жалост (или за щастие?) по онова
време почти нищо не схванах, само преписах част от кода като разбира се с грешки (който си седят и до сега).
Понеже преписване на код/текст от книга винаги ми е било омразно (особено набирането на компютър) реших да си
направя собствен, на C. И се роди window.h и mouse.h в root директорията Window. Това е по време когато още
нямах сегашната система за следене на промените на кода а и реално нямах никаква... Така, че датата на създаване
е приета условно XX.XX.2005, като за последен път е променян на 03.04.2006. Използваше се стеквия принцип на
управление на прозорците. Последния отворен е първия затворен. Да споменавам ли, че подържаше макс. около 10
прозореца? И, че нямаше никакви контроли? Тогава дори не очаквах, че някога отново ще се занимавам с кода.
Но времето си летеше неусетно, нямах нищо по-интересно за вършене но темата с управление на потребителския
вход/изход ме измъчваше все по-вече и по-вече. А и работата по АVR-OS ме държеше на вълна системен софтуер.
Това малко в страни. На 12.02.2007 направих пълна промяна на кода и започнах работа по Window Manager.
Window Manager реално започна от нулата. Беше разписан двусвързан списък за управлние на прозорците.
Идеята беше вземата от една OS - MajOS (дали?). Също най-големия проблем беше какъв подход за управление
да използвам? За добро или лошо реших да използвам идеята на M$ Windows. Съобщения, обработваща фнкция...
Всъщност сега като се замисля в по-вечето реализации и използват близки подходи (нещо като неписан стандарт).
Разбира се това бяха "тежки времена". Постояно се променяше нещо изоснови. например в едната варияция root
указателя на списака на прозорците се подаваше като параметър (dir: With Root Node), а след това стана глобална
промнлива. Мисля не овъртам с излишни подробности а направо да прескоча към сегашното състояние по Window Manager.
With MsgList (~20.02.2007 ~ днешна дата) е актуалния проект. Както се вижда от името, при него вече
съобщенията се записваха в лист, с цел избягване загубата на някое а и наподобяване на Windows. Да си призная
на места предпочиам дирекнто извикване на функцията на прозореца но това е отделна тема. Смятам за най-добре
е да спомема накратко какво имам постогнато засега. Контроли: бутон (button), поле за редакция (edit box),
главно меню на прозорец, pop up меню (не е баш контола де), char map - правоъгално поле съхраняващо и изобразяващо
елементи от ти char, статиче текст (label), tab order - последователност на обхождане на контролите на прозореца.
И наколко програми покзващи възможностите на прозоречната библиотека. В общи линии е това. Ще се опитам от днес да
описвам какви промени са извършени по кода. Особено тези който налагат преправяне на програимите реализирани с него.