Да, я это понимаю, я обладатель не самых лучших привычек, которые развил благодаря VB6. Но требования тогда были невысокие, для любой небольшой конторы самые критичные данные  -  их  базы  данных. Для написания, которых связка  VB+Access, VB+SQL не занимала вообще никаких усилий. Наверное многие (даже знающие Си)в те годы  использовали VB для создания СУБД. Очень рентабельно получалось. Да и не 3D игры же писать Бейсике!
Деваться некуда  буду учить. 
Только вот подскажи пожалуйста, какой подход мне лучше избрать. Но для начала немножко войди в моё не лучшее положение. 
Я человек взрослый, работаю, учиться в учебных заведениях мне не с руки (семью кормить надо). То образование которое я получал в 80-гг теперь уже = 0 (нулю). Да и что кто-то научит языку который вышел пол года назад (согласись версия 2005 это уже не 2003)  я  слабо  верю. Хотя конечно  есть гуру,  но  они  как раз  всегда  при  деле,  а  "не  за  партой". Ну и ещё два весомых фактора, которые давят так, что хоть кричи,  - в 40 лет не  так  просто заучивать, запоминать  и  разбираться  в  большом  объёме  информации. Второй  фактор, который  меня  просто  убивает  на  повал,  это  вот  это  новая  технология. Может  тебе  знакомо  такое со школьных  или  студенческих  лет  -  ну  никак  не  даётся  химия  или  французский! Или  ещё  лучший  пример,  который  всё  чаще  всплывает  у  меня  пред  глазами  -  90-е гг.  программист,  который  мне  в  отцы  годился, с  такими  большими  очками, толстыми  линзами,  говорит  мне  -  «Всё  что  делается,  теперь  делается  для  Вас,  для  молодого  поколения. Жалко,  что  только  про  нас  забыли. Наверное, мне придется  забыть про свою  профессию.» У  него  был  такой  безысходный  взгляд,  что  мне  его  жалко  стало. Помню,  он  так  в  сердцах  возмущался – «Да  что же  это  за  устройство такое придумали!» (про мышь, чувствовал,  наверное,  сердцем,  что  всё,  не будет  больше  ДОС-а) А  с  другой  стороны,  я  тогда  думал, "вот из-за таких  людей  у  нас  нет  прогресса!". 
Ты  смотр-ка,  как  в  жизни  всё  разворачивается.
Теперь  получи  и  распишись. Мне  даже  теперь жена  со  стороны  сказала, "ты  что-то  старшее  поколение  уважать  начал. Стареешь  чтоль?"

Так  вот  вопрос. 
Учитывая  всё  это,  но  самое  главное,  учитывая то  что  мне  этим  свой  хлеб  зарабатывать  надо  а  не  просто  "познавать  невиданное",  какой  подход  лучше  выбрать  для  изучения  "этого  ООП." Книгами  я  уже  обложился,  слава  Богу  Интернет  есть  и  дома  и  на  работе.(инет  - это  дар,  для  всех  программистов!) Но  чувствую  я,  что-то  не  так  я  делаю. Одно  только  ADO.net  чего  стоит. Но ведь  как-то же  люди  изучают  языки  за  пол  года! Если  у  кого  был  такой  этап,  и  он  пройден  хотя  бы  наполовину,  поделитесь. Что  является  залогом  успешного  изучения  такого  языка.? Ведь  "нахрапом"  не  возьмешь. 
Сейчас  я  пытаюсь  по  кусочкам  реализовать  то  что  у меня  было. Почему  это  не  правильно? Также  я  просматриваю  готовые  варианты  небольших программ,  которые  можно  скачать  в инете. Книги?  в  прицепе  да. Но,  например  мне  надо  решить  то-то  и  то-то,  в  книгах  такого  нет. Там  общие  решения. Справка  помогает, благо  английский  не  забыл. Но  ведь  наверное  не  так  должен  изучаться  новый  язык.?
В общем,  поделитесь  ребята.
Я  вот  тут  по-написал,  может  так  на  форуме  не  стоит  откровенно,  но  тяжко  мне,  честно. В реальной  жизни  вида  не  подаю,  но  в  уме  шок.
-------------------------------------------------------------------
Если  кто-то  ответит  на  моё  послание  даже  через  месяц  -  буду  рад.
 

Да, наверное, в моём возрасте учиться новому легче  . Но всё же. Я написал тебе выше ту книгу, которая тебе ОЧЕНЬ поможет. Я с её подачи и перешёл. После того, как нормально изучишь .NET, начинай изучать теорию. То есть читай Фаулера, Гамму и других классиков. 

Немного в оффтоп.
Если программа требует для своей работы Framework.NET - например Sony Vegas- значит ли это, что она написана на языке Visual Basic.NET ? 

Это значит, что она написана на каком-либо языке .NET, будь то VB .NET, C#, Delphi .NET, etc. 

Exception, 
Ясно 

к сожалению судить не могу, т.к. VB6 никогда в глаза не видел, а начал сходу изучать VB.NET, но думаю в каждой версии есть свои плюсы и минусы, будь то сложность разработки или качество...

Приемущество VB6 перед VB.NET: Заключается в том что у VB6 [Native Code], а это означает что программа работает под Win32, с использованием всего одной библиотеки, которая поступает уже вместе с XP. Весит эта библиотека в чистом виде 1 метр с хвостом (10 - 500 килобайт). У VB.NET, и других языков той же самой платформы .NET, Intermediate Language (промежуточный язык), который обязательно переводится в машинный язык, при старте. Первое: снижение запуска приложения! Обязательно Framework 23-25 мега(В будущем, возможно данный недостаток будет устранен).

Теперь по поводу недостатков VB6, VB.NET. Это пропорции. Это очень круто снижает скорость приравнивания/получения значения, нежели если мы будем обращаться напрямую к переменной. По мойму лучше написать процедуру приравнивания SetValue (ByVal Val As Value). 

VB.NET - Form->Control->Боевое снабжение на все случаи жизни. Если я не ошибаюсь то он используется визде, где нужен Visual Control. Размер в памяти у него очень не маленький. Можно даже сравнить используя NativeWindow и Control.

Все типы в VB.NET стали структурами, недостаток: меньше и быстрее реальная переменная (int), чем структура Integer в VB.NET.

Вообщем самая главная проблема .NET это оптимизация. Проги на данной платформе грузятся и выполняются медленне чем на платформе Win32. 


Хватит о плохом, пора переходить к хорошим!

Какая простота работа с массивами.


Можем спокойно в run-time создовать массивы практически любых типов.

А как легко создавать контролы в run-time, добавлять, удалять.


А как легко пишутся плагины 

А как легко модернизируются контролы

А как легко работать в VS 2003/VS 2005:)

А как легко дизайнить формы, с помощью конструктора.

А как круто, когда к Object можно передать любой тип (byte,short,integer,....,string,.....,control.....).

А как круто когда есть System.Windows.Forms, System.IO, System.Reflection, System.Runtime, System.Web, System.Net, и многие другие (есть и DirectX  манагед!). Кланю к тому что там столько классов, тока создавай и пользуйся ф-циями.

А как круто, конвертится:


А как круто выполнить динамический код в runtime.

+ковсему этому можно пределать то что степень риска вредоностности программы снижается! Т. е. не зделаешь на VB.NET вирус, хотя кто его знает. Ведь в VB.NET И др. языках .NET можно свободно пользоваться функциями из реальных библиотек работающих на Win32. Вообщем яб  рассказал как это возможно, но помоему незя этого обсуждать на форумах
Vingrada. 

Вообщем можно книгу писать Достоинство VB.NET И сех Language.NET.

Что хорошего в native code? Быстродействия он не обеспечивает, т.к. код целиком состоит из вызовов функций msvbvmxx.dll. Фреймворк будет поставляться с Windows Vista, конечно, он большой, но - сравни возможности библиотек! А преимущества .NET перед COM очевидны. Контроль версий (прощай, DLL hell), , стандарты языков, обеспечивающие межъязыковое взаимодействие. Богатый набор классов. Очень мощный GUI и фреймворк для взаимодействия с БД.
Ты ошибаешься: IL-код компилируется не перед стартом приложения, а перед выполнением метода в первый раз, причём результирующий машинный код можно оптимизировать. Если очень хочется - можно заранее скомпилировать весь код и запретить JIT-компиляцию с помощью утилиты ngen.exe.
Это ты свойства (properties) называешь "пропорциями"? К твоему сведению, из свойства SomeProperty компилятор генерирует два метода - get_SomeProperty и set_SomeProperty, так что я не понимаю, о какой потере производительности идёт речь.
Далее, что значит - "нужен Control"? Control - всего лишь базовый класс, какие к нему могут быть претензии  ?
По поводу переменных типа Integer - ты вновь ошибаешься. Они оборачиваются в структуру только по необходимости, и эта операция называется упаковкой (boxing). Дабы пояснить, приведу пример:На самом деле, только перед вызовом ToString в IL-коде происходит упаковка числа в структуру Int32. Поэтому в памяти числа занимают столько же, сколько и в C++, например.
По поводу кода создания массива - он вызывает ошибку компилятора, потому что ты пытаешься неявно привести тип System.Array к массиву Byte. Ошибку можно отключить, выставив Option Strict в Off, но это чревато ошибками, и за такой подход обычно дают пинка. На самом деле следует явно привести тип оператором CType.
По поводу того кода, который ты написал для конвертации: да, он работает, но этот подход не одобряется и присутствует лишь в VB .NET. В С# так делать нельзя. Ведь подумай сам: что делает функция CInt? Она приводит класс к Integer, если он это разрешает. У System.String этого оператора приведения нет. Поэтому правильно делать так:Также для конвертации можно пользоваться методами Parse, TryParse и подобными.
Да, ты совершенно прав, степень риска очень заметно снижается благодаря хитрой системе безопасности в .NET. Например, можно настроить систему так, чтобы сборки, загруженные из интернета, не имели доступ к файловой системе или, например, не могли вызывать/выполнять небезопасный код.

Это сообщение отредактировал(а) Exception - 4.10.2006, 15:22

 Очень большой. еслу не ошибаюсь, больше чем RedHat Linux 7.3. И требования к железе, тоже не малое.

 Все!

Насчет Properties: То что properties генерируют в функции get и set, я понял когда в C++.NET строил приложения. Я имею виду использовать функцию в том случаи, если требуется при преравнивании выполнить еще какие нибудь действия. А если просто потребуется получить, приравнить значение, то лучше обращаться на прямую к variable,  нежели стучаться в функции. И как ты думаешь, что быстрее: Прямая адресация к переменной, либо вызов функций?

Насчет ngen (и il), незнал. Попробую

Control - всего лишь базовый класс. Согласен. Размер смотрел этого класса? Даю 100% я напишу контрол "Button", которая в 20 раз быстрее и меньше чем при использовании Control. Конечно нельзя будет добавлять с помощью Controls.Add, но можно будет написать свой Array для контролов которые основываются на NativeWindow, либо еще ускорить написав структуру WindowClassEx. 

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

Я вот Exception непонимаю, для чего ты пишешь код? Для того чтобы им пользовались другие? если так, то пускай радуются что для них еще пишут. А то можно и вооще забить. Если я пишу какой то код, то для начала я убеждаюсь, что он в реале работает на определенном языке, и не стараюсь чтоб кто нибудь переписывал его на другой язык. Так что если пишу на VB.NET, мне грубо говоря напливать что кто то будет переписывать на C#. Пусть тогда сразу просить на каком языке ему приводить пример. А типа писать красивый код, чтобы другие любовались, пускай сами пишут для себя.

Насчет CType - привиди пример.  Array, у меня на VB.NET работают без глюков, и без сообщения компилятора. Все нормально компилируется, без установки опций. 

+Хорошего в .NET, не так сложно написать свой язык программирования(.NET).

А если тебе нужно чуть больше действий, чем просто обновить переменную? Например обновить контрол (обновил свойство text контрола). Причем это может понадобиться в дальнейшем. Не лучше ли сделать задел (причем очень простой) на будущее. 
+ для оптимизации кода существует компиляции в релизе. В ней уже компилятор убирает все ненужные переменные и заменяет гетеры и сетеры на реальные действия.

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

Насчет релизе - Release - это уже окончательное компилированние без доп. инфы относительно Debugerra. Когда то писал все под Debuger. А потом прочил что Release, максимально сжимает и оптимизирует выходной код. Ну естестно стал писать под Release. К стате если используешь Release то ошибки в коде(не путать с синтаксисом) не будет высвечеваться, если запускаешь из под студию. Лучше мастерить под Debug, а в самом конце компилить в Release, когда проект будет готов.

 Я и говорю, если нужно выполнить доп. функции.

А главное, какая аргументация!



В .NET всё равно ты не увидишь никакой прямой адресации  . Ибо нет прямой работы с памятью, и слава Богу.



И что? А что ты скажешь о переносимости твоего кода в перспективе под тот же, например Mono? О том, что же придётся делать бедняге, который возьмётся когда-нибудь за твой код, чтобы понять его суть? О работе твоего приложения, если WinAPI поменяется?



Для себя, других или заказчика.



А мне нет. Потому что в конце концов из VB .NET уберут всю эту VB6-дрянь.



Rubbish.

Красивый и понятный код вкупе с грамотным проектированием существенно сокращает стадию отладки и тестирования приложения.

Читай "Совершенный Код" Макконнелла.

.NET под Windows, не использует своей структуры (имею в виду Forms, Controls), а использует WinAPI, который полностью, или частично скрыт, от пользователя. Так что если перенести в Mono, или в ноый WinAPI, то из этого ничего хорошего не выйдет. Хотя если, переписать все библиотеки на другую платформу, или ОС (вчастности оставив прежнии названия процедур), то возможно переносимость обеспечена. Не могу утверждать, так как глубоко в платформе .NET не копался.


Ну это уже извращение, писать совершенный код под VB. Могу согласиться в том случаи если пишешь под Assembler. 


А вот за такие слова, и действительно можно получить в репу. А если уберут все ф-ции VB6, то буду тоскать библиотеку из VS2003, со своими приложениями


Это уже косается лично тебя.


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


Вот представь себе ситуацию: тебе предлогают VB компилятор, и VB интерпретатор. У них возможности одинаковы, за исключением конечно выходного файла. Что ты выберешь?

Интересная разворачивается дискуссия  .

Я говорю о том, что, если использовать исключительно классы Windows Forms, проблем с переносимостью, реализуй WF полностью в Mono, не будет. А завязываться на конкретных API.. какой тогда вообще смысл в использовании .NET, как не абстрагирование от этих API?

Не понял  ? А причём тут Ассемблер? Книжка называется "Совершенный код" и там написано о том, как следует писать код, чтобы его было проще отлаживать, модифицировать и добавлять фрагменты. Ни о какой производительности и речи не идёт  .

Зачем тебе функции VB 6? Чем тебе не нравятся аналогичные методы классов .NET Framework?

Скажи, зачем тебе нужно так извращаться с этой памятью? Указателей в .NET нет и не будет. Есть лишь специальные обёртки для них. Неужели ты действительно думаешь, что так работа ощутимо пойдёт быстрее? Тогда приведи два куска кода с тестами.

Я лично устал повторять, что .NET - никакой не интерпретатор. Я считаю схему с JIT-компилятором более расширяемой и универсальной, нежели схему с прямой компиляцией в нативный код, нацеленный на конкретную платформу. Да - кстати, VB 6 как раз и был интерпретатором.

Да они мне впринцепе и не нужны. Я могу полностью писать средствами .NET. Просто вьелись мне VB6, и се тут. Если ты говоришь, что вскоре уберут эти функции(т. е. библиотеку), то больше их трогать не буду.


Я просто привел пример языка, для которого, как я считаю нужно писать код, так чтобы можно было потом делать нормальную отладку, модификацию, и т. д.  А для VB.NET я думаю есть очень хороший стилист(редактор в VS7 и выше). Это я о красивом коде. 

Когда говорил о интерпретаторе, то не имел ввиду VB.NET:) И ты что так быстро устаешь? Развитие .NET, только начинается Еще знаешь сколько будут людей которые будут считать что .NET, это интерпретатор Как когда то я.


Приведу небольшой пример: в VB.NET есть таковой класс Bitmap(сам наверное знаешь). Скажем нужно приделать такую фичу, которая называется негатив. В класс Bitmap входят 2 функции (GetPixel, SetPixel). Единственное где можно использовать эти функции, то только если изображение не больше 124x124. А то ждать конца функции придется очень долго. Но если мы используем неуправляемую память, куда вобщем то и помищаются данные изображения, то данная функция займет считанные секунды, и разрешения изображения могут быть хоть 1024x1024. Поверь, это личный, горький мой опыт. Столкнулся я с ним, когда разрабатывал алгоритм увелечения изображения. Использовал я именно GetPixel, SetPixel, и изображение 320x240. Так запарился, что к черту проект стер. Только потом я узнал как работать с Unman. 
памятью.