Страницы: Пред. 1 2 3 4 5 6 7 След.
RSS
Возможности разработки взаимодействия с БД (выбор инструментов), Javascript ИЛИ VBScript
 
Хоть и кажется, что языки С++ и C#.NET это похожие языки, это только так кажется на первый взгляд и это не должно вводить в заблуждение.

Разрабатывать формы под WIN (!) на C#.NET значительно проще, вообщем они уже есть, просто конструктором надо собрать. Дописать логику - все.
С# это всегда Framework.

Для С++ Framework - не нужен.
На С++ нет стандартных конструкторов и форм, потому как С++ можно использовать не только под WIN (есть самописные движки под свою платформу или официальные среды разработки - с помощью них создаются игры под разные платформы). Здесь нужно использовать наработанные ранее библы и код, т.к. самому писать трудоемко. Но есть и плюс, можно работать на любой платформе.

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

Цитата
JeyCi написал:
с-файла, наверно, вместо vbc.exe использовать csc.exe
компилируйте через IDE, зачем вам командная строка.
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: На С++ нет стандартных конструкторов и форм,.... Здесь нужно использовать наработанные ранее библы и код, т.к. самому писать трудоемко
да, кстати, и header-файлы, видимо, могут отличаться в разных IDE... я в Dev C++ v.5.4.2 не смогла толком отобразить ваш код с "окно с двумя пользовательскими окнами ввода"... CreateWindowEx понимается. а CreateWindowW нет...  видимо, или соответствующих header-файлов нет или этот Dev C++ вообще ещё для winXP создавался, не win7... а при всех CreateWindowEx  - (внутри главного окна) какая-то окошка появилась с меняющимися значениями 0000 и 1 ...  
вобщем не вникаю, но похоже надо переходить на новые технологии - Фреймворки и весь их арсенал, нежели самописные библы и компиляторы для каждого отдельного языка... видимо, сила, действительно, во взаимодействии между языками и умении их подряжать под отдельные суб-задачи в рамках целого проекта... не понятно, как созданный на win7 клиент бд будет себя вести при переходе на win10 ??
Цитата
bedvit написал: Хоть и кажется, что языки С++ и C#.NET это похожие языки, это только так кажется на первый взгляд и это не должно вводить в заблуждение
bedvit, спасибо, что вывели меня из этого заблуждения ! и дали линк по языку (его классам, объектам, методам, наследованию и т.д.)...
p.s.
(для гостей топика) я там в ранних постах добавила линк по WebMethod для asp и по передаче json'ом из db (или условно table) in Asp.net C#
p.p.s.
теперь будет где развернуться  8)
Изменено: JeyCi - 21.05.2019 17:13:13
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
CreateWindowEx понимается. а CreateWindowW
Windows 95/98/Me: Функция CreateWindowW поддерживается при помощи Microsoft Layer for Unicode (MSLU). Чтобы использовать его, Вы должны добавить некоторые файлы к вашему приложению, как изложено Microsoft Layer for Unicode (MSLU) для систем Windows 95/98/Me.

А вообще CreateWindowW это обертка над CreateWindowExW (с поддержкой Unicode) см.спойлер
Скрытый текст

Переходите на современные IDE и компиляторы. Поставьте бесплатную версию студии от Мягкотелых (выше выкладывал ссылку) и не мучайтесь.

Цитата
JeyCi написал:
header-файлов нет или этот Dev C++
просто их нужно подключить (в современных IDE с этим нет проблем)
Изменено: bedvit - 21.05.2019 18:45:27
«Бритва Оккама» или «Принцип Калашникова»?
 
опять же, если нужны окна и формы - смотрите сразу WPF
Не тратьте особо времени на WindowsForms
 
Цитата
pharmaprofi написал: если нужны окна и формы - смотрите сразу WPF Не тратьте особо времени на WindowsForms
:oops: смотрела - смущал язык...
Основные сведения о языке XAML
Основы XAML
samples (правда старенькие)
p.s.
а как только что, с вашей подачи, начала вводить в yandex - xaml - сразу был предложен вариант - xaml c# учебник
===
думала, это похоже на xml, а оказывается программный код на c#, а подобие xml - это только контролы??
честно - просто не знала, на чём писать  8) и куда копать... вы вносите ясность и определённость... thanks
===
p.s.
Цитата
bedvit написал:
Windows 95/98/Me: Функция CreateWindowW поддерживается при помощи Microsoft Layer for Unicode (MSLU). Чтобы использовать его, Вы должны добавить некоторые файлы к вашему приложению, как изложено  Microsoft Layer for Unicode (MSLU) для систем Windows 95/98/Me. А вообще CreateWindowW это обертка над CreateWindowExW (с поддержкой Unicode) см.спойлер
тут уж думаю, с++ отпадает - после ликбеза от вас о том, что там ничего нет, и только код... только не понимаю, почему на нём "пишут игры и свои ос", если он такой пустой и писать нужно даже библы... может, он, действительно, уже в прошлом - может эти вещи (игры и свои ос) уже на java пишут (и даже, наверно, графически более богатые решения можно разработать, чем на c++) ??
Изменено: JeyCi - 22.05.2019 08:23:28
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
JeyCi, улыбнуло ) Открою вам страшный секрет, что формы в С# это тоже код! Просто за вас это написали, и поместили в подключаемые библы (помним про Framework?), часть вывели в мастер. И вообще, все что мы видим или слышим на ПК - это код (бинарный исполняемый железом). Т.к. все - код, на С++ я могу написать все что угодно, от пользовательских форм до драйверов любого оборудования на почти любую платформу. А на С#.NET только то, что позволит Framework и только там, где он есть (несколько упрощая). Чувствуете разницу?
Поэтому на С++ нет мастера форм, потому как ИМХО нельзя сделать к примеру форму, под все платформы, под разную архитектуру, с разным набором API, для микроволновки, для мобильного, для ПК.
Для каждого пишется своя.
т.к. С++ это Си с ООП, а Си в свою очередь "обертка" над языком ассеблера, решения на С++ быстрейшие из возможных (особенно с вменяемым копмилятором с хорошей оптимизацией). Поэтому на нем пишут программы для которых важна производительность (игры в том числе).
А по поводу библиотек для С++ их множество. Под свои задачи. Есть и движки (набор библиотек, инструментов). К примеру для графики, мощнейшее на сегодня решение (топ игры пишутся) unreal engine
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
JeyCi написал:
уже на java пишут (и даже, наверно, графически более богатые решения можно разработать, чем на c++) ??
топовые игры на своих движках на С++ или unreal engine (на мобильных платформах могут быть иные варианты)

Почему же С#.NET, Java заняли приличную нишу? Потому как уровень вхождения ниже, открыл IDE и пиши готовый продукт. Если не нужна топ-графика, высокая производительность, кроссплатформенность (к Java не относится), низкоуровневое программирование (к примеру драйвера) и т.д.
Быстро и вполне рабочий вариант.
Изменено: bedvit - 22.05.2019 10:21:29
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал:  JeyCi , улыбнуло ) Открою вам страшный секрет, что формы в С# это тоже код! Просто за вас это написали, и поместили в подключаемые библы (помним про Framework?), часть вывели в мастер.
bedvit, уж это я понимаю, просто - не хочется открывать библиотеку и разбираться, какими объектами и методами она оперирует, и что брать дополнительно из-вне и из каких др библиотек и ещё найти их... это же всё время... поэтому всегда выбираешь способности языка (уточню - библиотек, которыми он оперирует и которые имеются) под задачу...
Цитата
bedvit написал: на С#.NET только то, что позволит Framework и только там, где он есть (несколько упрощая).
вот это меня и смущало - а если его нет - может, он в пакет распаковывания внедрит нужное? тогда да, окошком не обойтись - нужно делать install-пакет...
Цитата
bedvit написал: А по поводу библиотек для С++ их множество. Под свои задачи.
та же ситуация - какие проект включит в себя, а на какие понадеется, а например при установке на win7 и win10 - вскроется ущербность использованных... и потом, я ведь сама не буду включать все - лишь бы IDE селективно запаковала в приложение то, что надо... а то, что надо - ещё пойди, да найди...или ещё хуже - пиши руками... тоже время и соответствующая квалификация нужна...
Цитата
bedvit написал: Если не нужна ... высокая производительность, кроссплатформенность
:) как раз нужна 1-ая... а 2-ая - только если в рамках линейки Windows...
Цитата
bedvit написал: Быстро и вполне рабочий вариант.
:) и это нужно...
хочется универсальности разработки максимальной - включая для дальнейшей модернизации проекта - т.к. сама тема ещё в изучении (и периодически обрастает новыми потребностями нужных выходных данных и интерфейсу [его навороты не нужны - чем проще тем лучше - т.к. выходные данные всё равно всегда будут значимы только в др. софте - кстати c-подобное считывание там])... да и логика входных данных иногда меняется - т.к. сайт сторонний с начальными данными, не зависящий от меня...
отсюда и задумчивость о выборе инструмента более, нежели о его графическом интерфейсе... (просто выделяю слово "графический", поскольку где-то видела, что "интерфейс" вроде класса - это совокупность свойств, методов и событий,  которые он понимает и оперирует ими)...
как-то так...
вобщем думала, как обойтись без Фреймворка (т.к. тоже всё-таки чужие библы и изменяются иногда - встречала на форумах мытания разработчиков при переносе проекта с более младшего на более старший фреймворк) - вот и думала, как по-проще и без него... НО не терять в скорости при Обращении с бд...  8) поэтому даже пробовала в txt писать vb [через ADO - даже видела, что он получше php - не помню чем], а потом компилировать руками - чтобы проще - но столкнулась с тем, что какой-никакой интерфейс всё равно нужен - а для него и и библы должны быть на компе по Контролам, даже самым простым (а компы бывают разные  ;)  и разной укомплектованности софтом (и соответственно регистрацией контролов в реестре, да и вставка их в vb, писаный руками - очень муторная) - даже я уже не помню, какие у меня библы откуда и что будет если переустановлю win)... вобщем, поняла обоснованность создания пакета set-up для установки приложения разработанного... лишь бы Фреймворк сам упаковывал, как надо... ( :( а то я ещё забуду, что упаковать по незнанию)... и про универсальность для разных Фреймворк установленных и для разныз win - тоже забывать не хочется...
Цитата
bedvit написал: Почему же С#.NET, Java заняли приличную нишу? Потому как уровень вхождения ниже, открыл IDE и пиши готовый продукт.
вот это не понимаю, почему в данном контексте вы опускаете VB.NET?? (или с ним какие-то проблемы?)
p.s.
в любом случае, спасибо
Изменено: JeyCi - 25.05.2019 07:15:19
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
почему в данном контексте вы опускаете VB.NET?? (или с ним какие-то проблемы?)
Исправляюсь, языки.NET. Потом все равно переводится в байт-код. Разницы в общем-то нет, с моей точки зрения. Просто на каких удобнее писать, на тех и пишите.
Начните с .NET.
Посмотрел WPF, графика там на DirectX, т.е. довольно серьезная. Формы можно красивые нарисовать. Но как по мне, несколько сложнее WindowsForms. Если нужна хорошая графика, возможно это стоит усилий.
Даже посмотрел, что люди пишут.
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал:
Посмотрел WPF, графика там на DirectX, т.е. довольно серьезная. Формы можно красивые нарисовать. Но как по мне, несколько сложнее WindowsForms.
Мне показалось даже проще.  Удобно задавать параметры элементов в текстовом редакторе. В forms вроде binding нету - то же штука полезная.
ИМХО, если и начинать копаться то сразу c WPF. А так те же яйца, но вид сбоку. Интерфейс это все вторично
 
Цитата
pharmaprofi написал: В forms вроде binding нету
да, вроде тоже не заметила... но мне в принципе нужны были только кнопки на форме... хотя, конечно, привязывание таблиц(выборок) из бд к GridView (например) - в WPF настроить руками достаточно быстро... если вдруг понадобиться
p.s.
конечно, скорость разработки на порядок увеличивается с Фреймворком, но, вероятно, и частота необходимых переделок при выходе новых версий Net.Framework... вобщем, тут главное - остановиться на каком-либо выборе  8) , а за все ваши впечатления - спасибо! теперь, действительно, есть из чего выбирать - с пониманием всех нюансов...
p.p.s.
bedvit, насколько помню вы как-то писали dll - вопрос возник: dll писаная на vs с net.framework, имеет ли ограничения в связи с использованием в дальнейшем только в среде с такой же версией NET.Framework ?? или получается достаточно универсальна под разную комплектацию компа софтом - разные установленные версии NET.Framework и версии win (7 или 10) ??
или с dll всё ещё проще, чем с контроллами?..
но ведь самостоятельную dll всё равно, наверно, не написать в vs - а только зависимую от внутренних библиотек framework'a... в отличие от с++ ... мне так показалось, что можно сделать такой вывод  ?
===
или dll - это уже не библиотека  8) [шутка или риторический вопрос]
Изменено: JeyCi - 23.05.2019 08:21:18
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
конечно, скорость разработки на порядок увеличивается с Фреймворком, но, вероятно, и частота необходимых переделок при выходе новых версий Net.Framework...
Переделывать не нужно. Версии Framework обратно совместимы. Если комп не совсем древний, то Framework уже встроен в ОС и обновляется.
 
Цитата
pharmaprofi написал:
ИМХО, если и начинать копаться то сразу c WPF
возможно, непосредственно не пользовался. Под простотой использования WindowsForms я подразумевал, что этот продукт из коробки, открыл студию, накидал нужную форму, контролы и т.д., все "мышкой", выставил свойства (итого можно без единого символа кода) и все можно писать логику.
WPF, я так понял, появился в студии, только с Visual Studio 2017 или более поздней версии (Visual Studio 2019 г.)

Цитата
JeyCi написал:
bedvit, насколько помню вы как-то писали dll
да побросало меня (С#.NET, С++, VB.NET, Си, СОМ, статистические, динамические, даже xll), хотелось бы еще на Java, но никак не поставлю JDK :), поэтому из практики и теории:
1.
Цитата
JeyCi написал:
dll - это уже не библиотека
DLL - это Dynamic Link Library — «библиотека динамической компоновки», еще есть статические библиотеки (если нужно, отличия напишу или можно погуглить).
dll на С/С++ - это native code - исполняется непосредственно ЦП (xll в этой категории)
dll на .NET  - это байт-код CIL, который посредством JIT-компиляции компилируется в native code (для этого нужен Framework).
Обязательно к прочтению:
CLR
CIL
JIT-компиляция
2.
Цитата
JeyCi написал:
но ведь самостоятельную dll всё равно, наверно, не написать в vs - а только зависимую от внутренних библиотек framework'a... в отличие от с++ ..
в VS можно писать на разных языках, С/С++,  .NET, VB (далее переход на VB.NET), F#, SQL, JavaScript (не путать с  Java), Python, наверное есть и другие.
Все, кроме .NET, не используют Framework
3.
Цитата
JeyCi написал:
dll писаная на vs с net.framework, имеет ли ограничения в связи с использованием в дальнейшем только в среде с такой же версией NET.Framework
обычно в новых версиях Framework, поддерживаются старые.
В настройках проекта (в студии) можно выставить нужную верcию Framework. По умолчанию используется 4.6.1. (поддержка начиная с Win7, см. рис.)
Изменено: bedvit - 23.05.2019 11:20:13
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: WPF, я так понял, появился в студии, только с Visual Studio 2017
ой нет - у моего vs2010 тоже есть... WPF появился, вроде, в 2008м...
а по вашему линку выше - в принципе, понятны основания для перехода или не-перехода на него
Цитата
bedvit написал: еще есть статические библиотеки (если нужно, отличия напишу или можно погуглить).
да можно и прогуглить - Статические и динамические библиотеки
и здесь- нюансы - в которые думаю, ещё очень много вникать надо... - когда всё написано правильно, а ничего не работает ИЗ-ЗА того, что линковка сработала косячно... спасибо, что обозначили этот момент, - чтобы знать, где ковырять... (обратить внимание на линк "нюансы")
Цитата
bedvit написал: По умолчанию используется 4.6.1. (поддержка начиная с Win7, см. рис.)
за скрин по ОС особое спасибо !
Изменено: JeyCi - 28.05.2019 07:30:25
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
ой нет - у моего vs2010 тоже есть...
Был неточен, ввела в заблуждение фраза:
"Предварительные требования
Visual Studio 2017 или более поздней версии (в этой статье используется Visual Studio 2019 г.)"
в теме от microsoft
Пошаговое руководство. Создание классического приложения WPF
«Бритва Оккама» или «Принцип Калашникова»?
 
мои выводы о сервере и БД такие - для ускорения быстродействия...
а вот для выбора реализации приложения - можно, полагаю, посмотреть  Visual Studio 2010: примеры для C# 4.0
и Создание простого приложения для работы с данными с помощью ADO.NET
и Создание простого приложения для обработки данных с помощью WPF и Entity Framework
всем спасибо за внесённую определённость, примеры и линки !! и за качественный ликбез !!
p.s.
C# Language ebook
Зиборов Visual C# 2010 на примерах
Изменено: JeyCi - 29.05.2019 08:10:48
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
bedvit написал: ввела в заблуждение фраза: "Предварительные требованияVisual Studio 2017 или более поздней версии
это, видимо, потому что Решения, созданные в более поздних версиях VS, не открываются в более ранних версиях VS... сами проекты... файлы .sln
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: Хоть и кажется, что языки С++ и C#.NET это похожие языки, это только так кажется на первый взгляд и это не должно вводить в заблуждение.
8) а вот и самое интересное (после линков из #43) - теперь понимаю ваши предпочтения к C#
p.s.
C# глазами Java
p.p.s.
(Java исользуется для создания Network Applications и иных кроссплатформенных решений - для моб.тел. и т.д. ... у C# синтаксис похож на него)
Изменено: JeyCi - 13.06.2019 07:20:10
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
и всё-таки respect to planeta !
вот она - моя проблема в скорости Access:
0) ну прежде всего, конечно, движок медленный (при переходе на MS SQL Server Express - некотрые запросы на результаты за почти полгода ускоряются с 10мин до 1 мин)
думаю, всё равно долго - и вот ответ аж 2005 - Выбор между Transact-SQL и управляемым кодом
Цитата
Transact-SQL лучше подходит для ситуаций, когда код выполняет доступ к данным с небольшим объемом или вообще без процедурной логики.
Языки программирования, совместимые с .NET Framework, больше подходят для расчетных функций и процедур со сложной логикой, или для ситуаций, когда Вам нужно использовать преимущества библиотеки классов .NET Framework
всё-таки мои математические обсчёты данных из БД - возможно, лучше проводить на стороне клиента !! (а Transact-SQL-ем только вытянуть)... понятное дело, в полной мере воспользоваться мощью сервера (как по статье) - у меня не получится (т.к. сервер софтовый на обычном hdd)... но
1) даже просто использование WITH X AS - качественно улучшит читабельность и правку кода, в случае необходимости... а в купе с хранимыми прцедурами и простоту запуска каскада запросов - без выстраивания сложных версий вложенностей подзапросов...  - уже плюс...
2) также перенос части вычислений на сторону клиента - всё-таки можно попробовать, хоть и имеются в сети наблюдения о том, что даже просто ООП может быть быстрее управляемого кода c# (неуправляемый писать, мне пока нет смысла - указатели и адресная арифметика [матрицы] в моём проекте отсутствуют, а писать ссборщик мусора самой - радости тоже мало)
3) т.к. считывание начальных данных для помещения в БД - может выполняться с помощью JSON.NET, что быстрее, чем Javacript Serialization/Deserialization -
то в принципе в свободное время стоит обратить внимание и на .NET Framework возможности, хотя Power Query пока справляется и в обслужвании проще - всё на виду... переделаю, только если удастся добиться выигрыша по скорости... сохранив комфорт обслуживания при изменениях на сайте...
- потому что всё-таки если не записывать json-файлы на диск для последующего парсинга в PQ (т.к. без этого в PQ были иногда зависания), то скорость парсинга "на лету" понятное дело сильно увеличится... хотя записывать данные в БД всё равно придётся (но хоть уберётся промежуточные запись-считывание в txt из http - что Долго)...
4) кстати загляну ещё на сайт - может там и API появилось, чтобы не править периодически парсинг, когда на сайте появляются изменения...
(5) да и, наверно, не стоит забивать до отказа сервер, а оставлять на нём часть свободного пространства для проведения запросов (что и есть вопрос памяти, вместо ram)
p.s.
понятное дело, что пересчёт индексов на Сервере - дело муторное - на 10гб - при обновлении бд, но скорость запросов за период, возрастающая с 10 мин до 1 мин при переходе с Access на MS SQL Server Express - это уже результат... а с использованием VIEW-х для запросов за нужную часть периода, не всей бд - думаю, даст то, что надо (как и with x as)...
p.p.s.
по поводу выбора C#.NET или VB.NET - поняла, почему приоритет отдаётся разработчиками C#-у: т.к.
Цитата
CLR создавался совместно с C#
=> на нём больше примеров и для него много библиотек, подключаемых через vs-пакет NuGet или просто, как Reference в проекте...
хоть библиотеки и от Visual Basic, т.к. своих у него не было,
но думаю уже типа CreateObgect (в VBA) или new ActiveXObject("ADODB.Connection") [для JavaScript] уже изобрели для С#...
- хотя, наверно, для NET и того проще - просто на reference проекта - библиотеку - и создание классов для работы с ней - полагаю, сила NET...  
а может, и сами некоторые dll (например упомянутая в начале топика msadox.dll) включают уже возможности для с-подобного использования (т.е. если она работает для JavaScript, то и на подобном C# труда не составит)
-- например newsoft.json (он же JSON.NET) раньше не встречала, чтобы работал на VB???.. или надо поискать примеры её (библы) использования в сети... (может новая библа, не из vb пришла)
+
в качестве конкурента для Java, возможно, C# ещё не совсем дотягивает по скорости, хотя писать асинхронные приложения ещё не пробовала на C#, а о многопоточности его написано очень мало - да и не разработчика это дело и не языка, а Мелкомягких
p.p.s.
при выходе более старших версий .NET Framework - всегда есть возможность, что написанные ранее приложения сами по себе начнут работать быстрее на более старшем .NET Framework (бывало такое у людей по отзывам) - даже править код не приходится
p.p.p.s доп
Изменено: JeyCi - 15.06.2019 08:17:01
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
всё-таки Script'овые языки - это Script'овые... и по быстрому... а для полномасштабной оптимизации проекта - стоит рассмотреть и новые инструменты  8) всем спасибо !
Изменено: JeyCi - 27.05.2019 17:08:28
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
кстати, не стоит упускать из виду технологию LINQ - язык запросов SQL-подобный, который встроен в язык C#.NET, VB.NET, С++ и др... запросы, которые можно выполнять к любому источнику данных: [наверно, самое интересное в .NET 8) ]
-- LINQ to JSON (вроде видела, если не ошибаюсь, что даже побыстрее, чем JSON.NET, что может быть понятно в виду краткости sql и похожести linq на него),
-- LINQ to Entity (linq to sql MS объявили "морально устаревшим" поскольку он выполнял запросы только к SQL Server, а linq to entity к любой бд)
-- LINQ to Array
-- LINQ to Collections
etc.
p.s.
и не претендую на истину, но что-то крутится в памяти, что ADO.NET при каждом следующем вызове в приложении выполняет +1 запрос (в придачу к предыдущим) -- т.е. странность какая-то есть у него: выполняет все предыдущие и последний заданный, и выводит результаты последнего (в консоль например)
Изменено: JeyCi - 13.06.2019 09:42:00
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
и при всех наворотах Visual Studio - всё-таки стоит осилить Программирование в консоли
p.s.
вопрос изначально из моих интуитивных знаков вопросов, наверно, так и стоял "как соединить консоль с графическим интерфейсом?"... оказывается в IDE Ultimate++ - это .lay файл в проект (где дальше рисуй, что хочешь), а в с# - это всё-таки resource модуль...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
JeyCi, тема холиварная, но все же добавлю. С моей точки зрения, топик по ссылке выше несколько однобоко подходит к сравнению, комментариев тоже к ней нет, что как бы символизирует.
Плюсы описанные в той теме по программированию в консоли:
Удобство в работе
Мобильность
Долгосрочные перспективы.
Опенсорсные проекты.
Работа на слабом железе
Удаленная работа
Психологический аспект

Согласитесь, что кроме последнего - круто, я умею программировать на ассемблере в консоли, не очевидные преимущества. Особенно первый пункт.
А как же профилирование производительности, памяти, дебагер, подсветка синтаксиса (иногда реально помогает), переход по ссылкам функций, переменных, классов. Возможность быстро посмотреть перегруженные функции и т.д. Это все есть в IDE, но почему то не упоминается в той теме. Это тоже все просто делается в консоли?
Тем более удаленная работа сейчас может делается сразу командой программистов, через репозиторий (хитхаб и другие), что прекрасно сочетается с IDE  (для справедливости, с репозиторием можно работать и с консолькой).
Изменено: bedvit - 13.06.2019 10:04:01
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: Работа на слабом железе
:) а всё-таки может придётся когда-нибудь "на коленках" с ноута...
Цитата
bedvit написал: А как же профилирование производительности, памяти, дебагер, подсветка синтаксиса (иногда реально помогает), переход по ссылкам функций, переменных, классов
соглашусь! особенно первых 3 пункта от вас - святое
Цитата
bedvit написал: Возможность быстро посмотреть перегруженные фунцуии и т.д. Это все есть в IDE
bedvit, вот тут и ступор у меня - поэтому комфорта не вижу - т.к. нет обычных для vba (например) окон Locals и особенно Debug в Immediate?? - поэтому жму кнопку Отладка - а вижу только ошибки описанные внизу после исполнения... а переменных во время ошибки зафиксить (чтобы посмотреть, как в Locals в vba) не могу -- вот и чувствую себя, как без рук... да и stop сделать не могу, чтобы опять же увидеть переменные в середине работы кода...
мне поэтому и кажется, что увидеть хоть что-то (о переменных в процессе) можно только в консоли (при разработке в Visual Studio) - иного пока не нашла...  :(
Изменено: JeyCi - 13.06.2019 10:09:28
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
JeyCi, все есть. Я сейчас освобожусь напишу вам.
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
JeyCi  написал:
т.к. нет обычных для vba (например) окон Locals и особенно Debug в Immediate?? - поэтому жму кнопку Отладка - а вижу только ошибки описанные внизу после исполнения... а переменных во время ошибки зафиксить (чтобы посмотреть, как в Locals в vba) не могу -- вот и чувствую себя, как без рук... да и stop сделать не могу, чтобы опять же увидеть переменные в середине работы кода...
Все есть, см. рис. (точка останова отмечена красной меткой, желтая стрелка - строка на которой остановлен процесс выполнения программы).

[QUOTE]
Изменено: bedvit - 13.06.2019 11:07:12
«Бритва Оккама» или «Принцип Калашникова»?
 
Описание свойств, переменных в классе

Профилирование (ЦП). Есть еще памяти (куча, стек) и прочие см. рис.

Перегрузка функций (на данном слайде перегрузка конструктора строки std:: )
В данном случае 16 разных перегрузок.
Изменено: bedvit - 13.06.2019 11:07:26
«Бритва Оккама» или «Принцип Калашникова»?
 
JeyCi, надо бы поднять матчасть по работе в этой IDE.
Погуглите, много тем по этому вопросу.
к примеру Работа с Visual Studio
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал:  JeyCi , надо бы поднять матчасть по работе в этой IDE.
ой сколько всего - а то google всё как-то разрозненно выдаёт... и thanks for link - буду поднимать мат.часть  :) ... и спасибо за потраченное время!
p.s.
а то я всё справку читала в VS...  :oops:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: -- например newsoft.json (он же JSON.NET)
только дополню свои выводы из #49 -- а ведь парсинг в управляемом коде может и не пригодиться -- т.к. начиная с Server 2016 есть JSON-комманды самого сервера... - на заметку
Изменено: JeyCi - 16.06.2019 18:14:44
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
Страницы: Пред. 1 2 3 4 5 6 7 След.
Наверх