Форум пользователей Visio

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

в групповой фигуре состоящей из 5 шейпов…

Да вроде все нормально...т.е. ответ на заданый вопрос, без отсылок к МСДН и их корявым примерам...
Геннадий, вот в этом и вопрос - а где, собственно, читать-то? Ну ваше практическое руководство - понятно, лежит передо мной )) А еще?...Причем о серьезных вещах, а не для чайников...пока этот сайт - лучшее, что есть.

Так, теперь по теме - а чем такая группировка лучше обычной?

Вот примерно об этом я и говорю.
Сначала вроде бы должна быть глобальная задача, потом рассуждения - какими путями и технологиями она достигается. И где-то в конце под выбранные решения просто создается нужный шейп (если нельзя сделать штатными). То есть шейп - это мелочь, которая делается ближе к концу.
А в данном случае как раз главная задача неизвестна. Начинаем плясать от шейпа и задаем вопрос "как лучше". Так замучаешься на этот вопрос ответить. Может как раз лучше такой шейп вообще не делать, а сделать либо совсем другой, либо даже не хитрый шейп, а макрос, работающий с простыми шейпами.
----------
А в общем-то, это все мысли по поводу... Не нужно принимать это как критику.

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

ни чем по сути. просто мне так визуально больше нравится, набор шейпов все равно тот же. шаги тогда будут такие
1. рисуем все из чего состоит группа: внешний контур, поля и стрелки
2. группируем все это
3. коннекшн пойнты добавляем к групповому шейпу, по его контуру (на концы стрелок)
4. обзываем коннекшины - тупо пишем имя в пустом столбце слева
я давно ни чем почти "штатным" не пользуюсь, т.к. под мои задачи ничего 100% не подходит (изредка пользуюсь шейпами из набора Floor Plan).
думаю, в данном случае речь шла о разных шейпах. я предложил, как бы я это сделал сам. я не показал ничего сверхестественного, далеко до статей Digitall™
"Штатные" шейпы предназначены для составления схем из готовых наборов элементов, или автоматизированного построения с помощь опять же "штатных" аддонов. так что в любом случае их придется допиливать под себя. а для начала придется перебрать все наборы и посмотреть, что и как устроено. уйдет куча времени и совсем не факт, что неподготовленный пользователь поймет что же задумали разработчики. powercat писал, что его интересует обмен данными - в как это делается в штатных аддонах, тайна покрытая мраком!
почему нет? в спорах рождается истина ! глобальная прога состоит из множества более мелких составляющих. большая просьба разбивай свою сверх-задачу на части и задавай отдельные вопросы в отдельных темах!
и сумбура будет меньше в обсуждении, твоя задача полностью точь-в-точь на 100% мало кому не подойдет. но шанс, что ее составляющие принесут пользу другим пользователям выше !

---

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

А какая роль у этого шейпа?
1. Это основной элемент редактирования? Типа, с помощью него будет строиться изображение и вводиться данные?
2. Или он будет выполнять функцию индикатора - отображать некое число для того объекта, к которому его приконнектят?
Если второй случай, то для шейпа полезно поведение, как для выносок. Чтобы он таскался за основным объектом и светил данные.
Если первый, то функциональность явно слабовата. Я что-то не могу придумать применения такому шейпу.
И еще один момент. Я так понял, что на этот шейп-индикатор возлагается еще и функция распознавания типа источника данных. То есть если его к чему-то присоединять концом "газ", то тот объект становится газом. Опять же не знаю глобальной задачи, но чаще бывает по-другому - объект источник данных знает свой тип, а присоединяемый индикатор считывает этот тип и отображает данные в нужном окошке. Именованная точка соединения у меня вызывает подозрение.

Все вопросы, которые я тут задаю, они являются лишь абстрактными. И автобус, и газ с водой - только крохотные примеры, но решение которых мне просто необходимо для основной работы. Зачем вас еще грузить моими задачами полностью, вряд ли вам это нужно ))) Они у меня глобальные, массивные...Поэтому я спрашиваю какой-нибудь максимально простой пример, вы даете максимально понятный ответ - и вуаля, я встраиваю это в основную работу.
Поясню детальнее - основная задача - написание программы визуальной работы по перспективе работы в моей сфере - скважины, подземное оборудование, наземное, расчеты в них, обмен с базами, обмен с расчетными программами участие Эксель и т.д., т.е. очень большая программа.
Вот. Оно вам надо вникать в это?
Поэтому я спрашиваю что-нибудь очень простое, но решающее локальную проблему. Потом на этой базе делаю что-то в своей работе. И вам просто, и мне.

По шейпу - он и основной объект, он и индикатор (прямо на нем что-нибудь будет меняться). Да, он будет распознавать связи, вернее не он, а контроллер. На основании связей будет делаться всякие другие штуки...Но вам оно вряд ли надо ))) Я, когда дойду до этого, задам какой-нить опять же простейший вопрос )))

та боже упаси !
а то сейчас сам напишу такую программу и начну на даче добывать нефть !!! это безусловно! я бы и сам не сказал
единственное, что каждый из нас с высоты своего опыта мог разбить твою сверхзадачу, на составляющие возможно более эффективно! как в том примере коллективной работы: у нас ушло несколько дней и около десятки сообщений, пока я не догадался о какой схеме идет речь )

с подобными схемами я отдаленно имел дело. и предложил на ходу поменять затеи автора. в отдельнной ветке wellcome. больше новых веток - больше hardcore !!!

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

можно программно передать в шейп параметр и все вычисления выполнить средствами shapesheet. а не кодить это

Не, чтобы за меня думали, как оптимальнее - не мой вариант ))) Мне требуется только какой-то конкретный ответ, не более. И вам проще, и мне, т.к. есть алгоритм и под него делаю программу ))
Не знаю, что такое однолинейная схема, но моя программа будет интерактивная, с кучей всякой дополнительной хрени, кнопками и т.д., а не просто рисунок с суммированием каких-то значений.
Не, что-то рассчитывать на уровне самого визио - это зло, разве что в каких-то ОЧЕНЬ узких задачах. Обычно я разделяю модель данных, GUI, и их контроллеры - т.е. визио понятия не имеет о данных, его задача только отображать то, что ему скормит контроллер (даже нажатие кнопки обрабатывается просто диалогом, а в классе кнопки НИЧЕГО нет), а данные понятия не имеют о визио, они должны быть обработаны в модели и забраны котроллером. Такая схема позволяет в любой момент менять любую часть программы с минимальным трудом. А если все завязать на визио, то что-нить удалив получишь полную жопу )))

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

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

GUI - даже для себя стараюсь делать красиво, мне ж тыкать в кнопки ))) Ну и опять же это опыт программирования...Ибо я может в следующем году свалю в Штаты, а там хочу работать в IT, а не в надоевшей до ужаса нефтянке...

Почитайте теорию прежде чем что то городить).

Кстати, в таком случае Visio Guy Forum может быть для Вас гораздо более полезным, чем этот. Все-таки и информации, и пользователей там побольше...

В теории ровно это же и написано - разделение. Особенно явно это относится к андроиду. Оформление, разметка, данные, обработчик, мост.

Да, но пока довольно сложно на английском сформулировать мысль...Ибо поймут не так, а программу-то писать надо.

+1
боюсь для этого видеоуроков будет маловато. нужны сертификаты и реальный опыт работы
такое точно не прокатит
а это тем более

Вот не всегда это так...
То, что хорошо для одного типа приложений, может совершенно не подходить для другого.
А формальное применение такого принципа разделения зачастую приводит к повторному программированию (дублированию) функций, имеющихся в Visio. Уходит лишнее время, а чаще всего еще и ухудшается качество.

Да, может и быть дублирование. НО - это позволяет уйти от косяков...Например, умеет ячейка шейпа 3 рассчитывать квадратный корень. А заказчик сказал:"Мне не нравятся такие квадратики (шейпы 3). Уберите это и сделайте чтобы было всплывающее сообщение"...Все, приплыли...А в моем подходе ВСЕГДА будет - не вопрос, шейп3.текст удаляем, мсгбокс ставим и скармливаем ему это же число/переменную...

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