ferzmikkВот писал разные макросы в Excel. Visual Basic.Net не много отличается Visual Basic. Хотя Visual Basic.Net это самостоятельный язык программирования. Насколько возможно excel-ий файл с макросами открыть в Visual Studio, преобразовать его (
и при этом изменяет логику так, что обойдется без Excel файла ), но сохраняя алгоритм подключении, расчетов, формы, вместо вывода данных (ListObject, PivotTable, Chart, PivotChart и т. д.) на лист отображает на своих объектах, чтобы в конечном итоге появился exe-файл?
Тот Бейсик, что в Эксель - это скриптование. Насколько я знаю, там вам готовые объекты с готовыми данными окружения (контекстом) предоставляются, и вам просто заполнить скриптик надо. Вы сами не собираете этот контекст, вы вообще не разрабатываете иерархию классов и их взаимодействие. Вам как будто предоставили готовый скелет программы, и вы только пустые функции заполняете. Это как в ASP.NET MVC методы контроллеров заполнять с готовыми контекстами, как джаваскриптить, когда тебе браузер весь контекст доступа к DOM'у и переменным окружения предоставляет, как на Unity 3D писать, как шейдеры на видеокарте по готовым заполненным структурам входящих и выходящих векторов.
Если вы действительно собрались изучать С++ и С#, как в начале темы сказали, а до этого только скриптовали, то вам в принципе надо изучить, что такое функции и классы (если вы не чистой функциональщиной собрались заниматься), наследование и инкапсуляция, и более сложные вещи, типа шаблонов. Это гораздо сложнее, чем просто скриптование. А потом уже лезть во фреймворки и создание офисовских файлов чисто на языке (при этом рекомендую всё же C#, а не С++, если вы не ретроград с
MFC ). C++ сейчас вообще для винды редко где применяется, если вы не разработчик игр. Если вы обычный "формошлёп" (не в негативном смысле), то вам C# за глаза и даже лучше, ибо перспектив больше, а проблем меньше.
ferzmikkwinsky!мне здесь одному кажется, что у вас бред?
Программка будет формировать разные отчеты.
Скажем каждая кнопка 1, 2 и 3 формирует какую то небольшую обработанную таблицу, подключенную к OLAP, и
выводит ее .
И будет четвертая кнопка, которая
формирует такой отчет , при котором выгружается несколько таблиц из OLAP, и происходит вторичная обработка путем соединений этих таблиц с помощью локального SQL. Возникает вопрос, зачем писать sql запросы к данным, полученным из MSAS. Сам не сторонник такого способа. Четвертый отчет он очень сложный, новый, и пользователям сложно описать как конкретно должен выглядеть отчет, и как должно все считаться. Приходится со временем менять математическую модель, формулы, структуру, оформление. После того как конечным пользователям будет устраивать математическая модель, структура, соблюдение указанных правил, условии, то модель будет конечной и делаем запрос на то, чтобы нужные поля с конечной логикой добавить в OLAP. Потом кнопка 4 будет просто
выгружать конечную таблицу из OLAP без дополнительных обработок. Получается с помощью вторичной обработки
формируем экспериментальный отчет .
Это всё будет выгружаться в Excel? В дотнете можно создавать экселевские документы в коде, но для этого всё же стоит хотя бы бегло пробежаться, как вообще программы, хотя бы формошлёпные, в нём писать. Если вы не собираетесь применять всякие WVVM (вам это не надо), и надо, чтобы просто 4 кнопки формировали эти ваши отчёты, то можно создать простое оконное приложение и в обработчиках событий нафигачить ваше формирование экселевского файла. Только непонятно, зачем для этого вообще C# нужен и оконное приложение с 4 кнопками.
YUBAНо, все таки, через годик пришлось уйти на C#. А сейчас и его не хватает - медленно мигрирую на С++, который, кстати, предполагает включение в код NET функциональности.
Настолько всё насыщенно работой с памятью, что сборщик мусора является узким местом и без С++ никак не обойтись?.
