-
/1247620-2885312134_1e80bd8362_o.jpg)
Динозавры! Ауууу!!!
Теги:
Реконструктор
Resurrector>>У MFC серёзные проблеммы с многозадачностью. Если вам надо писать прогу с несколькими потоками + GUI, лучше MFC не трогать.
Владимир Малюх>Да ну? А мужики-то и не знают (с)
И как это у нас софт работает?Владимир, ничего личного, но когда я уведел у вас java аплеты в роли плагинов, я сам себе задал этот вопрос
инфо
инструменты
Владимир Малюх
Resurrector>Владимир Малюх>Да ну? А мужики-то и не знают (с) И как это у нас софт работает?
>Владимир, ничего личного, но когда я уведел у вас java аплеты в роли плагинов, я сам себе задал этот вопрос
Хм, компромисс. Ну где я вам найду пользователей-инженеров, способных на СР++ писать? VBA прицеплять по ряду причин не хотелось. А пятилетний опыт жизни с Java оказался совсем не самым страшным К тому же безопасно - умер апплет и фиг с ним, сама программка жива и данные юзерские тоже.
И как это у нас софт работает?>Владимир, ничего личного, но когда я уведел у вас java аплеты в роли плагинов, я сам себе задал этот вопрос
Хм, компромисс. Ну где я вам найду пользователей-инженеров, способных на СР++ писать? VBA прицеплять по ряду причин не хотелось. А пятилетний опыт жизни с Java оказался совсем не самым страшным
К тому же безопасно - умер апплет и фиг с ним, сама программка жива и данные юзерские тоже.
Maschinen muessen "idiotensicher" werden
TEvg
кстати видел в магазине левый bCAD. долго мучился - купить или нет.
Владимир Малюх>Хм, компромисс. Ну где я вам найду пользователей-инженеров, способных на СР++ писать? VBA прицеплять по ряду причин не хотелось. А пятилетний опыт жизни с Java оказался совсем не самым страшным
К тому же безопасно - умер апплет и фиг с ним, сама программка жива и данные юзерские тоже.Перед взятием решения, однако, стоит делать т.н. research, т.е. исследование на предмет нахождения наиболее подходящей технологии. Я бы, например, внедрил Windows Script Hosting (
). Ты, конечно, можеш утверждать, что javascript труднее джавы, но я такое не посмел бы утверждать.
И вы считаете, что это проблема MFC?! Вообще програмирование с потоками подразумевает их синхронизации. Я уже не говорю, что создавать поток под MFC используя CreateThread некошерно.
Slowspeed>И вы считаете, что это проблема MFC?! Вообще програмирование с потоками подразумевает их синхронизации. Я уже не говорю, что создавать поток под MFC используя CreateThread некошерно.
<em />
Вообще програмирование с потоками подразумевает их синхронизации.
Не подразумевает. Лень писать тот-же самый пример, но без MFC, попробуйте написать сами. С удивлением увидите, что проблем не будет.
В том то и разница: Если в этом конкретном случае использовать MFC, то надо создавать класс для IDD_DIALOG1, потом посылать туда WM_NOTIFY или что-то другое, в целом надо синхронизировать. Если сидеть на голом API, никакой синхронизации не нужно. 
.cpp
Реально полезные средства синхронизации - критическая секция и функции управления/ожидания событий.
Перед взятием решения, однако, стоит делать т.н. research, т.е. исследование на предмет нахождения наиболее подходящей технологии. Я бы, например, внедрил Windows Script Hosting
Он нам не подошел тогда по уйме причин, сейчас лень документы ворошить - решение-то принималось в 96-м году или даже в 95-м, не помню уже.. Достаточно одной низкой производительности и "неизобразительности" GUI.
Он нам не подошел тогда по уйме причин, сейчас лень документы ворошить - решение-то принималось в 96-м году или даже в 95-м, не помню уже.. Достаточно одной низкой производительности и "неизобразительности" GUI.
Maschinen muessen "idiotensicher" werden
>Реально полезные средства синхронизации - критическая секция и функции управления/ожидания событий.
Сама ф-я окна является функцией ожидания событий
Я думаю мы о разных вещах говорим. Та синхронизация, которую я имею в виду заключалась бы в добавлении WaitForSingleObejct(hThread) в WM_DESTOY.
А вообще много проблем не имеют простых решений и если они не возникают там где они должны быть (по крайней мере потенциально), значит скорее всего вы их просто не заметили и проблема в том, что вы не понимаете, что они на самом деле есть.
А вообще много проблем не имеют простых решений и если они не возникают там где они должны быть (по крайней мере потенциально), значит скорее всего вы их просто не заметили и проблема в том, что вы не понимаете, что они на самом деле есть.
>Перед взятием решения, однако, стоит делать т.н. research, т.е. исследование на предмет нахождения наиболее подходящей технологии. Я бы, например, внедрил Windows Script Hosting
Владимир Малюх>Он нам не подошел тогда по уйме причин, сейчас лень документы ворошить - решение-то принималось в 96-м году или даже в 95-м, не помню уже.. Достаточно одной низкой производительности и "неизобразительности" GUI.
Врать, Володя, нехорошо.
Java родилась в 95-том, реальную популярность получила после 97-го.
Slowspeed>Я думаю мы о разных вещах говорим. Та синхронизация, которую я имею в виду заключалась бы в добавлении WaitForSingleObejct(hThread) в WM_DESTOY.
Slowspeed>А вообще много проблем не имеют простых решений и если они не возникают там где они должны быть (по крайней мере потенциально), значит скорее всего вы их просто не заметили и проблема в том, что вы не понимаете, что они на самом деле есть.
Slowspeed>А вообще много проблем не имеют простых решений и если они не возникают там где они должны быть (по крайней мере потенциально), значит скорее всего вы их просто не заметили и проблема в том, что вы не понимаете, что они на самом деле есть.
Slowspeed>Я думаю мы о разных вещах говорим. Та синхронизация, которую я имею в виду заключалась бы в добавлении WaitForSingleObejct(hThread) в WM_DESTOY.
?!?
:o :wacko:Slowspeed>А вообще много проблем не имеют простых решений и если они не возникают там где они должны быть (по крайней мере потенциально), значит скорее всего вы их просто не заметили и проблема в том, что вы не понимаете, что они на самом деле есть.
ыыыы...аааа.....?! Прости, я сегодня не философски настроен
Хе. в этом смысле мне линь больше нравится: гибчее и обильней. Ассемблег гуёв - мотиф|лессиф... и поехало
"... аще где в книге сей грубостию моей пропись или небрежением писано, молю Вас: не зазрите моему окаянству, не кляните, но поправьте, писал бо не ангел Божий, но человек грешен и зело исполнен неведения ..."
>>Slowspeed>Я думаю мы о разных вещах говорим. Та синхронизация, которую я имею в виду заключалась бы в добавлении WaitForSingleObejct(hThread) в WM_DESTOY.
?!?
:o :wacko:Guest>Чему вы так удивляетесь? Давайте пожалуйста более развернутые ответы, а то с вами неудобно общаться.
Kaк Вы ЭТИМ предотвратите поломку MFC в данном примере.
>Врать, Володя, нехорошо.
Java родилась в 95-том, реальную популярность получила после 97-го. Оно тогда сразу же и принималось, ей богу, по горячим следам. Значит в 96-м все-таки. Во всяком случае в 97-м мы прототип bCAD с Java API уже показывали на выставке в Милане
Maschinen muessen "idiotensicher" werden
>>>Slowspeed>Я думаю мы о разных вещах говорим. Та синхронизация, которую я имею в виду заключалась бы в добавлении WaitForSingleObejct(hThread) в WM_DESTOY.
?!?
:o :wacko:Guest>>Чему вы так удивляетесь? Давайте пожалуйста более развернутые ответы, а то с вами неудобно общаться.
>Kaк Вы ЭТИМ предотвратите поломку MFC в данном примере.
А что - не предотвращу? Может быть - о сложных вопросах нельзя говорить походя. Все-таки думаю, что на самом деле основная проблема тут все-таки в том, что нарушено главное правило создания потоков - под MFC - нельзя создавать потоки иначем чем спомощью CWinThread. Попробуйте - замените CreateThread на AfxBeginThread - может и окажется, что проблема в том, что автор примера просто не дочитал MSDN.
TEvg>кстати видел в магазине левый bCAD. долго мучился - купить или нет.
Мы одно время собирали, потом надоело
Мы одно время собирали, потом надоело
"Будьте самоучками - не ждите, чтобы вас научила жизнь." С.Е. Лец
Resurrector>Сама ф-я окна является функцией ожидания событий
Я бы сказал - обработки прерывания, вызванного событием.<! />
>>Врать, Володя, нехорошо.
Java родилась в 95-том, реальную популярность получила после 97-го. Владимир Малюх>Оно тогда сразу же и принималось, ей богу, по горячим следам. Значит в 96-м все-таки. Во всяком случае в 97-м мы прототип bCAD с Java API уже показывали на выставке в Милане
Володь, не обижайся, но внедрять ННТНБ (Неопознанные Новые Технологии с Неясным Будущем) основная ошибка менажера.
Однако, истины ради, в то время (до 98-го) у тебя выбор действительно был невелик. Но по моему (гм, в действительности оно так и есть), если соградить софт как следует, с хорошей объектной моделью и соблюдая стандарты COM-a, то инструмент создания плагинов можно пользовать какой-угодно, вкл. потребительский выбор того самого инструмента.
>Resurrector>Сама ф-я окна является функцией ожидания событий
Я бы сказал - обработки прерывания, вызванного событием.<! />
ComputerMage
>>Slowspeed>Гм. Боюсь тогда Windows-то не было
.>Был Windows-2
.Он самый. Квадратный, оконно-неперекрываемый =)
Быть или не быть?!
Вот только у кого спросить?!
Вот только у кого спросить?!
asoneofus>А можно на Qt
И не парить мозги 
asoneofus>Кстати, Владимир, с чего это вы решили, что MFC безальтернативна?
ИМХО, это неплохое средство, но не лучшее.Тока не Qt!
Он тяжелый как мамонт.
Я под Иксы на Xlib пишу. Абсолютно несложно, зато идёт под любым оконным менеджером =)
Быть или не быть?!
Вот только у кого спросить?!
Вот только у кого спросить?!
ComputerMage> Он тяжелый как мамонт.
Ща, типичное заблуждение Если для 100МГц проца и 16М ОЗУ - не тяжело, то... что вы с ней сделали?
ComputerMage> Я под Иксы на Xlib пишу. Абсолютно несложно, зато идёт под любым оконным менеджером =)
Угу, и под виндой? А на маке как? А если иксы не фрёвые? А если иксов вообще нет?
Ща, типичное заблуждение
Если для 100МГц проца и 16М ОЗУ - не тяжело, то... что вы с ней сделали? ComputerMage> Я под Иксы на Xlib пишу. Абсолютно несложно, зато идёт под любым оконным менеджером =)
Угу, и под виндой? А на маке как? А если иксы не фрёвые?
А если иксов вообще нет?
"... аще где в книге сей грубостию моей пропись или небрежением писано, молю Вас: не зазрите моему окаянству, не кляните, но поправьте, писал бо не ангел Божий, но человек грешен и зело исполнен неведения ..."
Copyright © Balancer 1997..2018
Создано 09.06.2003
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 09.06.2003
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
