Все, Finish!!!

[SLIM]

Сколько можно...
Пишу проект, пишу в VS, пишу на чистом API.
Исписал сотни страниц бумаги, написал 2000 строк, постоянно отлавливаю баги, посвещаю проекту по 5 часа в сутки...
Ну задолбался я на API писать. Конечно все хорошо, но чтобы сделать элементарное приходится перечитать кучу информации, понять, переварить.... плюс некоторые баги в студии...
Задолабало.
Вспоминаю VB, скучаю, мечтаю о нем.

Скажите, это я один такой дебил что решил писать приложения таким образом?
Может стоит таки потратить время и писать такие вот прикладные задачи например на том же Builder-е. Или вообще на Delphi перейти.

Ну или может кто меня успокоит и я продолжу путь...
Устал мусолить проект с элементарным функционалом...

[FireFenix]

VB .NET ?
Все фитчи и плюшки в доступных обёртках и поданы на блюдечке с доками на мсдн И тот жий WPF таки рулит по части красивого и функционального ГУИ

[SLIM]

NET отпадает сразу...

[FireFenix]

NET отпадает сразу...

Почему?

[SLIM]

Ну...нет и все.
Хватит того что я смотрю в сторону VCL-ки...

[1Steps]

NET отпадает сразу...

А зря. В соседней теме ты изголяешься через апи с сортировкой листвью.
А знаешь насколько просто это сделать в .net? Два свойства и одна функция.

А вообще, от програминга надо отдыхать. Иногда бывает так, что напишешь строку, а потом долго думаешь зачем я её написал.

[Twister]

Честно говоря, я не понимаю, почему SLIM в соседней теме мучается с сортировкой. Я самолично реализовывал её на API, все работало как часы.

По поводу реализации БОЛЬШОГО проекта на API: если только в целях академического интереса, в ином случае лучше поглядеть в сторону VCL. В отличие от .NET там всегда в случае необходимости можно ввернуть и API, и ассемблер. Хотя 2000 строк... Это нельзя назвать даже проектом средней величины, особенно если все пишется на API. Скорее всего, SLIM, ты просто не привык еще. Пройдёт чуток времени и освоишься.

[SLIM]

Честно говоря, я не понимаю, почему SLIM в соседней теме мучается с сортировкой. Я самолично реализовывал её на API, все работало как часы.

Да работает все как часы, я же все таки сделал.
Но вот смотри.
1. Обработать в WM_NOTIFY нотификацию LVN_COLUMNCLICK
2. В структуру LPNMLISTVIEW получить данные - там номер столбца.
3. Послать контролу LVM_SORTITEMS, где в WPARAM передать номер столбца, в LPARAM - функцию сортировки, которую реализую.

Функция сортровки. Она имеет три параметра - lParam1, lParam2, lParamSort.
В lParamSort попадает наш номер. В lParam1 и lParam2 попадают lParam-ы Item-ов.
1. Создаем два тестовых буфера, структуру LV_FINDINFO, в ней ставим флаг LVFI_PARAM и lParam равный соответствующему lParam1 или lParam1(смотря что ищем)
2. Шлем LVM_FINDITEM,и ищем с помощью структуры FINDINFO нужный Item - получаем его индекс (так для обоих сравниваемых элементов)
3. Глем LVM_GETITEMTEXT и получаем в буфер строковые значения Item-ов
4. Далее сравниваем два буфера, например с помощью wcscmp. Возвращаем результат сравнения.

Вот это - самый простой вариант.
После того как я это сделал, передохнул. Сижу думаю - числа сортируются неверно, это косяк. Направления сортировки нет. Тоже косяк.

Берем направление сортировки. Передать направление сортировки мы можем только где-то в нотификации или заиметь глобальную переменную, чтобы в функции сортировки проверялось значение и если что, умножать результат на -1 перед возвратом. Я выбрал передавать направление сортировки передавать в нотификации когда шлю LVM_SORTITEMS. Для этого создал структуру, где два поля, одно - это номер столбца (раньше мы передавали только его), второе - направление (булева переменная). Передаем ее адрес через WPARAM.
Пришла эта дрянь в мою функцию сортировки. Там значит нужно заиметь такую же переменную структуры и закастовать указатель в lParamSort.
Ок, теперь проверяем поле структуры на предмет направления, все ок, работает (если этого всего не сделать, то сортировать будет только в одну сторону и только раз).

Осталась проблема с сортировкой чисел. Тут вообще косяк. Список у меня динамический. Какие поля, какой их наименование я задаю в xml-файле, обновление его проходит в отдельном потоке. Обновляется все - и столбцы и сами данные.
Ок, дальше. Для того чтобы сортировать числа - нужно строку преобразовать в число. Ну например с помощью _wtoi. Потом отнять от одного другое (у нас же два сравниваемых item-а) получим результат (который еще умножим на -1 если наравление сортировки не то)
Ага, как сортировать числа мы поняли.

Но вот список то динамический, я не могу закрепить за каким-то столбцом - мол ты, это число, а ты, это строка. И преобразовывать всегда для первого столбца в число, а для второго оставлять сортировку строк.
Поэтому придется в xml-ку добавить помимо наименования столбцов и их порядка - еще и тип данных. И вот уже в функции сортировки читать xml файл и смотреть каждый столбец, как же его сортировать. Это самый простой выход. Он ужасно кривой, так как с xml я работаю через COM, а для функции сортировки это будет дорогостоящая операция - скорость я думаю упадет значительно. Можно было бы еще на начальном этапе, когда обновляется список читать в какую-нибудь структуру все что нужно - и наименования столбцов и их типы. А потом обращаться к этой структуре в функции сортировки. Но для того чтобы так сделать - пришлось бы поправить добрую часть проекта.

А вот если бы я знал на начальном этапе, что мне предстоит сделать когда еще писал функцию заполнения ListView, я бы возможно все сделал. Но я ведь не знал какие извращения меня ждут.

И вот после всего этого я уже расстроился. Ведь это только один пример, один камень. А у меня их было....И скажи теперь Twister, это мало? Ведь каждое действие не просто было сделано, его сначала нужно было узнать, прочитать, 100 раз ошибиться и т.д.


А так хотелось написать хорошее приложение. Чтобы оно было гибким,чтобы оно могло настраиваться как захочешь, чтобы оно не зависало (тут вообще отдельная история с кучами потоков, ожидающих таймеров, событий и других объектов для синхронизации)....а вот что получается

[Dmitriy2003]

SLIM, кто-же сможет тебя уговорить писать на чём-то конкретном, кроме тябя самого.

Я вот не согласен с FireFenix, 1Steps, Twister, а толку, у каждого свое представление. Наверняка есть люди для которых написание проектов на чистом API (ASM) так-же легко и непринужденно как для меня на С# - но это ведь мало что значит, стал бы я их убеждать что многие задачи я делаю быстрее чем они ? Нет, не стал-бы поскольку в этом нет смыла и это не правда.

Вот Twister пишет в .NET отсутствует прямая поддержка API, ASM (Managed VC давай пока не трогать), так ли это плохо ? Ну кому-то это может показаться серьезным недостатком. Однако, всё-же есть P/Invoke - и с решением многих задач он справляется успешно, как вариант предлагаю прочитать статью. Асинхронные операции с устройствами

А вот FireFenix, 1Steps - пишут, что VB.NET (WPF, WCF и бог еще знает что...) самый простой, имеет огромную базу документации, и предосталяет широчайший выбор готовых компонентов применимых в повседневных проектах - так сказать "по щелчку".

Ну опять - же правда ли это ? Ну допустим компоненты есть, тока вот все ли они так хороши ? увы нет (часто нет того или иного), часто приходиться расширять функционал класса, очень часто появляются неизвестные ранее баги. Все это не смертельно и с этим можно справиться доп.усилиями. Что касается документации, так она и у Сишников есть и немаленькая, а даже по больше будет.

В общем вывод таков - раз уж ты потратил столько времени на освоение API, не знаю на чем ты там писал на С или С++..., наверняка теперь отказываться не рационально, лучше малость отдохнуть, а потом энергично браться за дело снова, и не мечтать о языке, которого, как это ни прискорбно, как такового "больше нет".

[Хакер]

Просто поражает, с каким удовольствием определённые люди пишут о языке и о том, что он умер и его больше нет.

[Dmitriy2003]

Просто поражает, с каким удовольствием определённые люди пишут о языке и о том, что он умер и его больше нет.

Удовольствие я от этого не получаю, и visual basic мне раньше очень нравился

[Хакер]

Язык не умер и не исчез.

Файлы в отличие от большинства вещей на свете не подвержены старению. Они не изнашиваются, не устают, не подвержены коррозии и деградации.

VB6 сегодня — это тот же VB6, что и 12 лет назад. Ни один байт его компилятора не изменился. Все недостатки, которые есть сейчас (а их много), были сразу же на момент выхода. И, тем не менее, на этом языке, используя этот инструмент, было разработано огромное количество проектов, были написаны километры исходников.

Другое дело это стереотипы и заблуждения в головах. Продукт вышел давно — значит он автоматически плох.

[Proxy]

Он не плох, а неактуален (т.е. в среде популярного на сегодняшний день ПО и железа необходимо прикладывать определённые усилия для обеспечения совместимости проектов с API наиболее распространённых мелкомягких ОС, графическим интерфейсом ОС и т.д).
И опять таки кроссплатформенность отныне очень даже приветствуется ввиду довольно высокого распространения опенсорсных ОС (кроссплатформенность не значит "существует эмулятор"), Visual Studio и сейчас похвастаться особо-то и нечем.

[Twister]

SLIM

Но вот список то динамический, я не могу закрепить за каким-то столбцом - мол ты, это число, а ты, это строка.

Здрасьте. Для таких целей заводится массив, описывающий поля. В моём последнем проекте каждый элемент такого вот массива содержал подавляющее большинство необходимой информации, вплоть до названия поля из таблицы БД, значение которого отображается в столбце.

А вообще я могу сказать одно. Если ты пишешь на API, то должен чётко представлять ЗАЧЕМ ты так делаешь. Я бы в жизни не стал писать на голом API многофункциональную обёртку к БД, интерфейс у которой строится динамически (мой текущий проект). API надо использовать там, где это действительно принесет выигрыш.

[SLIM]

Здрасьте. Для таких целей заводится массив, описывающий поля. В моём последнем проекте каждый элемент такого вот массива содержал подавляющее большинство необходимой информации, вплоть до названия поля из таблицы БД, значение которого отображается в столбце.

Все верно, абсолютно верно. И нужно так делать. Список формируется на основании запроса к базе. Я имею и наименования столбцов и то как они будут называться в списке и где они будут располагаться.
Но вот я же и говорю, знал бы я что придется так извращаться с сортировкой, так бы и сделал. И дело даже не в плохом планировании проекта, а в том, что когда я за него сел, я расписал все в силу своих знаний и логических рассуждение о том как должно работать то, чего я не знаю. К сожалению, в силу своего небольшого опыта я не все могу предугадать правильно и сланировать на все 100. Вот и выходят косяки.

А вообще я могу сказать одно. Если ты пишешь на API, то должен чётко представлять ЗАЧЕМ ты так делаешь. Я бы в жизни не стал писать на голом API многофункциональную обёртку к БД, интерфейс у которой строится динамически (мой текущий проект). API надо использовать там, где это действительно принесет выигрыш.

Вот и я о том же. Нужно знать зачем. Для меня было просто интересно как оно там все происходит, чтобы знать как работают обертки и т.д. Но просто надоело. А вот знать что принесет выигрышь это или нет - это уже другое дело. Что значит принесет выигрышь? Как это понять? Как выявить, нужно ли писать на API?

Вот писал я как-то проект, нужно было чтобы приложение сворачивалось в трей. Думаю что штатными средствами этого не сделать ни в VB, ни в Builder-е, ни в любом другом - специфичная задача то. Здесь нужно явное использование API. Но не писать де весь проект на API в этом случае, верно. Но и сабклассинг - тоже утомительная вещь. Получается какой-то гибрид непонятый, который потом, возможно, придется латать.

Вот и стоит делема - где и когда что нужно. За этим собственно и топик был...


По поводу VB.
Да вы что. VB - это супер система. Это (как выразился однажды мой хороший, но бывший друг) - очень удобная COM-обертка для любой работы. Если что-то не позволяет сделать язык - пиши библу на другом, юзай в VB. И правда удобно.
И даже больше - я наверное вернусь еще к нему, когда нужно будет написать что-то прикладное и рабочее. Но только после того как освою все низы...

По поводу NET.
Не могу судить плохая ли это платформа, не плохая ли она. Но меня больше привлекает писать без посредников (мне даже сишный рантайм бывает беспокоит, но куда же без него то...), когда я знаю что вот здесь делается именно так, а все остальное - это обертка над этим действием. Но я знаю что делается в этой обертке. А вот с NET - не знаю. И копаться очень долго и трудозатратно. Поэтому лезть не хочется, хотя, возможно, и заслуживает внимания.

Заставить или упросить меня конечно никто не может. Просто хочется совета. Может просто передохнуть и продолжить и я на правильном пути, или же сменить направление...

[SLIM]

Да, спасибо, Хакер. Нужно было в блоге писать.

[FireFenix]

Я вот не согласен с FireFenix, 1Steps, Twister, а толку, у каждого свое представление. Наверняка есть люди для которых написание проектов на чистом API (ASM) так-же легко и непринужденно как для меня на С# - но это ведь мало что значит, стал бы я их убеждать что многие задачи я делаю быстрее чем они ? Нет, не стал-бы поскольку в этом нет смыла и это не правда.

Человек сказал, что ему сложно вести большой проект, а я - что в .НЕТ всё уже реализовано, бери и юзай не изобретая велописеда...
То что .НЕТ умеет или не умеет или можно делать по другому - это отдельный разговор

Ну опять - же правда ли это ? Ну допустим компоненты есть, тока вот все ли они так хороши ? увы нет (часто нет того или иного), часто приходиться расширять функционал класса, очень часто появляются неизвестные ранее баги. Все это не смертельно и с этим можно справиться доп.усилиями. Что касается документации, так она и у Сишников есть и немаленькая, а даже по больше будет.

У сишников нету WPF, т.е. конструировать гуи как HTML и стилизировать они не могут

Вот и я о том же. Нужно знать зачем. Для меня было просто интересно как оно там все происходит, чтобы знать как работают обертки и т.д. Но просто надоело. А вот знать что принесет выигрышь это или нет - это уже другое дело. Что значит принесет выигрышь? Как это понять? Как выявить, нужно ли писать на API?

ну ну товарищЪ! С вашим интузиазмом АПИ функи тоже не столь юзабельны, ведь они тоже обёртки на процессорными коммандами
Вообще .нет хорошо рефлектится (кроме моей грёбанной версии рефлектора) и можно заглянуть внутрь... естесно для полного понимания можно почитать мсдн, сопоставить в знании апи и получиться полная картина

Вот писал я как-то проект, нужно было чтобы приложение сворачивалось в трей. Думаю что штатными средствами этого не сделать ни в VB, ни в Builder-е, ни в любом другом - специфичная задача то. Здесь нужно явное использование API. Но не писать де весь проект на API в этом случае, верно. Но и сабклассинг - тоже утомительная вещь. Получается какой-то гибрид непонятый, который потом, возможно, придется латать.

Ну а вот почему бы не использовать .НЕТ? Там всё можно сделать 3-10 небольшими строчками без заморочек, и причём не только такие тривиальные вещи... Т.е. оставить на МС произодительность FW, а себе делать упор на правильную концепцию структуру проекта... типа по фен-шую +)
Вот у меня щас проект, где динамически создаются контролы в разных потоках в произвольной последовательности и вложенности, да ещё их нужно переодически заполнять, обновлять и прочие мелочи.... чтобы это всё писать на АПИ... я бы умер... у меня и так на .НЕТ уж больное громоздкая архитектуру что рвёт моск...

По поводу NET.
Не могу судить плохая ли это платформа, не плохая ли она. Но меня больше привлекает писать без посредников (мне даже сишный рантайм бывает беспокоит, но куда же без него то...), когда я знаю что вот здесь делается именно так, а все остальное - это обертка над этим действием. Но я знаю что делается в этой обертке. А вот с NET - не знаю. И копаться очень долго и трудозатратно. Поэтому лезть не хочется, хотя, возможно, и заслуживает внимания.

ну лишние знание не помешают... для начала можно посмотреть примеров и сопоставить как это выглядит в коде - т.е. удобнее ли чем было или нет, а потом поняв структуру легко находить нужные плюшки, даже не лазия в мсдн

Заставить или упросить меня конечно никто не может. Просто хочется совета. Может просто передохнуть и продолжить и я на правильном пути, или же сменить направление...

Можно просто притормозить.... оценить выполненную работы и скока ещё осталось... если есть время возможности и стремления к усовершенствованию проекта - то можно взглянуть на другие языки и посмотреть как с ними рабоать, удобно ли? или может эффективнее, приятнее и т.д.

Думаю как-то так...

[SLIM]

Ну не мое NET, вот не тянет меня к нему и все.
Пробовал в свое время в VB.NET сидеть. Ну не покатило.

Человек сказал, что ему сложно вести большой проект, а я - что в .НЕТ всё уже реализовано, бери и юзай не изобретая велописеда...

В том то и дело что проект не большой. И вести его можно. Но трудозатратно. Знаю что имея за плечами этот проект дальше будет легче. Многое будет уже изучено и известно как применять.

ну ну товарищЪ! С вашим интузиазмом АПИ функи тоже не столь юзабельны, ведь они тоже обёртки на процессорными коммандами

Ну никто не спорит. Везде есть уровень абстракции. Никто не пишет в чисто императивных языках...да и есть ли такие.
Но все мы знаем, что в принципе, мы не заглянем внутрь какой-нибудь API-библы. Она в своем роде атомарна. Можно найти и исходники, и смотреть что делается в отладчике. Но все равно. Все ведь на них построено в рамках данной ОС.

делать упор на правильную концепцию структуру проекта... типа по фен-шую +)

Вот это боюсь и есть самое сладкое для NET-программистов, что завлекет все больше и больше людей.

Мы, увы, и так ушли от основ программирования. Раньше программист имел хорошую математическую базу, знал всю теорию, ил часть ее. А тут вообще - программирование мышью. Нет уж, увольте. Хоть чуть чуть да хочется думать.

[FireFenix]

делать упор на правильную концепцию структуру проекта... типа по фен-шую +)

Вот это боюсь и есть самое сладкое для NET-программистов, что завлекет все больше и больше людей.

Мы, увы, и так ушли от основ программирования. Раньше программист имел хорошую математическую базу, знал всю теорию, ил часть ее. А тут вообще - программирование мышью. Нет уж, увольте. Хоть чуть чуть да хочется думать.

Нууууу...... залог хорошей конструкции - быстрое понимание, редактирование и дополнение... А если делать упор на минимальную абстракцию, то можно много времени потратить на реализацию, а основа будет плохая и её нада будет каждый раз переписывать, чтобы улучшить.... т.е. часть внимания самой архитектуре и взаимодействию компонентов не столь высок как если бы был бы выше уровень абстракции, т.е. как в .НЕТ
Т.е. чем выше уровень абстракции, тем больше уделяем внимания архитектуре и композиции, но ставим под сомнение производительность (хотя тут спорно... думаю FW писали люди не глупые) и понимание

Хотя если маленький проект, то почему бы не написать на Си + АПИ? можно хоть на ассемблере, главное чтобы было интересно и приятно

Вообще нужно исходить из цели и взвесить - что и как лучше, и какой язык приоритетнее в данном случае... если знаешь несколько...

[Хакер]

Куда смотрит Microsoft, столько одержимых людей в отдел рекламы.

[SLIM]

Хакер, высказался бы...

[Хакер]

Куда уж мне, я всеми силами постараюсь не допустить промолвить хоть звука, который, не дай боже, заразит тебя моими неправильными мыслями, которые, с твоих слов, делают человека неуспешным.

[SLIM]

Я сказал что был не прав. Что еще то...

[SLIM]

Поставил Builder 2007. Хотел вскрыть себе вены.
Поставил Builder 6 - желания не убавилось. Как блин тут все устроено. И уже мой проект кажется не таким страшным

[iGrok]

Поставил Builder 2007. Хотел вскрыть себе вены.

Прокси, зачем ты взломал аккаунт SLIM'а?

[SLIM]

iGrok, порадовал старика

[1Steps]

А вот FireFenix, 1Steps - пишут, что VB.NET (WPF, WCF и бог еще знает что...) самый простой, имеет огромную базу документации, и предосталяет широчайший выбор готовых компонентов применимых в повседневных проектах - так сказать "по щелчку".

Ну не VB.Net а .Net. И скажи, разве это не правда?

Ну опять - же правда ли это ? Ну допустим компоненты есть, тока вот все ли они так хороши ? увы нет (часто нет того или иного), часто приходиться расширять функционал класса, очень часто появляются неизвестные ранее баги.

В данном случае не столь важно на сколько хорош компонент. Важно то, что есть основной функционал, который ты можешь дополнить на свое усмотрение так как ты хочешь. И(как сказал FireFenix), не нужно изобретать велосипед.
Для примера.

Исписал сотни страниц бумаги, написал 2000 строк, постоянно отлавливаю баги, посвещаю проекту по 5 часа в сутки...

А спроси его, сколько дней уже он пишет, умножь на 5 часов в сутки и..., дальше всё понятно. А теперь спроси нетчика, сколько ему надо времени написать 2000 строк кода, при готовом алгоритме.
Мне, при готовом алгоритме, надо не более 5 часов. Разница очевидна, не так ли? И скажу больше. При правильной настройке студии, 80% багов отловит компилятор во время написания.

Ну и самое главное, я не утверждаю, что .Net лучший, я говорю, что писать в .Net намного легче чем в чем либо другом.

И последнее, больше я на эту тему не спорю. Останусь при своем мнении.

[SLIM]

И правда сколько стронников NET.
Никто не спорит что быстрее. И удобнее.
Но это большая, громоздкая платформа. Изучение ее займет даже больше времени чем той же практики в API.

[Dmitriy2003]

Ну и самое главное, я не утверждаю, что .Net лучший, я говорю, что писать в .Net намного легче чем в чем либо другом.

Упрощая: .NET = CLR + FCL; CLR <- IL - так вот если писать на IL - то желание вскрыться появиться ещё раньше чем от Builder'a
SLIM, 1Steps - надеюсь, эта мальнькая шутка вас не задевает.

[FaKk2]

Ну не мое NET, вот не тянет меня к нему и все.

О чем тут говорить?... Не тянет, так не тянет. Тяни свою лямку как умеешь.