roboforum.ru

Насколько я помню базовый класс вызывает вроде всегда свежие методы, разве нет?

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

да, неплохо бы

есть базовый класс System.IO.Ports.SerialPort. наследую его и добавляю в него фенечки:
- параметры по умолчанию
- массывы с доступными параметрами

Код: Выделить всё

  public int[] baudRates = { 300, 600, 1200, 1800, 2400, 4800, 7200, 9600, 14400, 19200, 38400, 57600, 115200, 128000 };
  public int[] dataBits = { 5, 6, 7, 8 };
  ...
 

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

Код: Выделить всё

        new public string PortName
        {
            get { lock (locker) return base.PortName; }
            set
            {
                lock (locker)
                {
                    if (!IsOpen && null != value && "" != value) base.PortName = value;
                    NotifyPropertyChanged("PortName");
                }
            }
        }


но есть поля (IsOpen, CtsHolding, DsrHolding), которые в базовом классе непонятно кто и когда может изменить, по крайней мере я не уверен, что могу полностью учесть все нюансы базового класса. CtsHolding, DsrHolding и еще несколько полей вообще пока не трогал и не разбирался с ними (и скорей всего не буду).
IsOpen в базовом классе естественно только для чтения. написать примерно так я не смогу

Код: Выделить всё

        public override bool IsOpen
        {
            get { return base.IsOpen;}
            private set
            {
                base.IsOpen = value;
                NotifyPropertyChanged("IsOpend");
            }
        }


частично помогает вот такое переопределение

Код: Выделить всё

        new public bool IsOpen
        {
            get
            {
                lock(locker)
                {
                    if (_lastIsOpen != base.IsOpen)
                    {
                        _lastIsOpen = base.IsOpen;
                        NotifyPropertyChanged("IsOpend");
                    }
                    return base.IsOpen;
                }
            }
        }


но сэттер я в таком случае просто не смогу реализовать. написать

Код: Выделить всё

            private set
            {
                .....
                NotifyPropertyChanged("IsOpend");
            }


можно, но толку от этого 0 по модулю - сэттер базовый класс просто не вызовет (или я как-то через одно место переопределяю?)
отловить все изменения IsOpen скорей всего смогу по эксэпшинам и переопределением Open и Close. т.е с уведомлением об изменении интересующих меня полей проблема будет решена. но это всего-лишь один из классов, к которому я добавляю функционал и создаю UI обвёртку, есть классы, в которых я такими способами никак не смогу отследить изменения.

Ну я примерно понял. Ты хочешь нарушить инкапсуляцию чужого объекта. Так? И не стыдно?

да в том-то и дело, что не хотса криводод плодить - как раз занимаюсь вылизыванием кода и приведением его к нормальному виду. неудобство в том, что SerialPort и куча других классов не реализуют интерфейса INotifyPropertyChanged, который решил бы все проблемы. ленивые пагшоиды, там же всего-ничего кода добавить можно было, на вскидку строк 20-30 от силы.
хороший вопрос, а нафига этот весь изврат вообще нужен? всё оч просто - UI и биндинг. для наглядности вот пример проги (нужен .Net 3.5)

Я к тому что твоя затея явно противоречит одному из 3 основных принципов ООП - инкапсуляции. Может не стоит и пытаться? все настройки с проверкой пропертей по таймеру или при вызове метода get это всё как раз достаточно жесткий кривокод.

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

Повторяю - этот маленький прикол противоречит одному из 3 китов ООП - инкапсуляции.

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

чудненько, наконец-то немного разобрался с артулкитом


Добавлено спустя 50 минут 36 секунд:
не удобно снимать двумя камерами, нужно приловчиться

Прикольна А зачем это?

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






вот кстати неплохая леговская реализация


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

шутники

чё за фигня?