"Супер Окна" походу совсем даже не супер :(

[Hirurg]

Вот прочел комменты к посту ТБМ http://www.tybet.ru/content/comments/index...10#message21510

много нового узнал, про Супер Окна и позицию ТБМ, какой-то неприятный осадочек остался.

Прошу высказать свое мнение пользователей Супер Окон по поднятой в коментах теме, Айболитом.

[Стекольщик — добрый и жадный]

Компания «ТБМ» пишет про ограничение кол-ва символов в артикуле с/п:

 

Ограничение в 20 символов заложено изначально в программе, поэтому для изменения данного поля потребуется изменить всю структуру программы. А это, сами понимаете, слишком затратно. Также непонятно, зачем столько много символов? Ведь это определённые неудобства в дальнейшей работе менеджеров.

 

НЕВЕРЮ!

 

20 символов либо ограничены в поле ввода, либо в базе.

 

Слова про изменения отдельного поля, которые потребуют изменения всей программы - тоже, мягко говоря, преувеличение. Это просто отговорка человека, не занимающегося программированием, и "перелопатить" 1 поле - явно не будет стоить космических денег.

 

"Болтовня ничего не стоит - покажите мне код!" Линус Торвальдс

[Стекольщик — добрый и жадный]

Вот ради интереса слил из сетки базу к СО, и увидел то, что ожидал. Какой-то хороший человек поставил ограничение в базе на длину поля в 20 символов:

 

 

Если это ограничение снять, то и проблемы с длиной артикула должны уйти.

[Стекольщик — добрый и жадный]

Поправил, теперь бы на практике проверить. Но сам СО не пользую, нужны добровольцы

 

[Rexther]

Поправил, теперь бы на практике проверить. Но сам СО не пользую, нужны добровольцы

 

Не так все просто как кажется ....

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

 

Но по- сути поднятого вопроса: очень интересен диалог разработчика с пользователями ... Интересен его результат и формат ...

[Стекольщик — добрый и жадный]

Это я какую-то старую базу откопал оказывается. Современные версии так просто не сдаются

 

Совершенно согласен, что покупатель приобретает осознанно, и с точки зрения разработчика на каждый чих не наздравствуешься.

 

Я из чисто спортивного интереса эту тему смотрю. С точки зрения программирования - всего надо увеличить длину поля в базе, а в софте - снять ограничение на длину поля.

 

Я сделаю оговорку, что с форматом ДБ, используемым в СО я никогда не работал, и не представляю нюансы. А они нарисовываются так, что база зашифрована, и есть какие-то трудности, не позволяющие ручками через редактор внести длинный текст. Вникать до победного откровенно лень, я от СО далек.

 

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

 

Да, диалог и впрямь интересный. Меня лично несколько позабавила фраза о том, что для изменения длины артикула придется переделать всю программу за много денег. А делов то в дельфи открыть искодник и сделать поправку.

Изменено 28 августа, 2011 пользователем Стекольщик — добрый и жадный

[Rexther]

Это я какую-то старую базу откопал оказывается. Современные версии так просто не сдаются

 

Совершенно согласен, что покупатель приобретает осознанно, и с точки зрения разработчика на каждый чих не наздравствуешься.

 

Я из чисто спортивного интереса эту тему смотрю. С точки зрения программирования - всего надо увеличить длину поля в базе, а в софте - снять ограничение на длину поля.

.......

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

 

Да, диалог и впрямь интересный. Меня лично несколько позабавила фраза о том, что для изменения длины артикула придется переделать всю программу за много денег. А делов то в дельфи открыть искодник и сделать поправку.

Ну можно взять БД от ПС - она не зашифрована. Там тоже есть ограничение на длину поля артикула.

Самое забавное, что и у нас подобный вопрос возникал недавно ... И повод был, кстати, похож ....

И ответ ...

 

И дело не в том, что нет желания и пр. А в том, как мне разъяснили программисты, что программу и БД из-за длины одного поля именно, что придется лопатить глубоко ...

И про быстродействие - не мои домыслы.

[Стекольщик — добрый и жадный]

А в том, как мне разъяснили программисты, что программу и БД из-за длины одного поля именно, что придется лопатить глубоко

Очень может быть. Софт оконный сложный.

 

Мои домыслы основаны на опыте работы с аксессом и пионерском опыте программирования на VB.NET. Исходя из опыта, не понимаю, в чем может быть засада, но это не значит, что я прав. Но поковырять бы надо, так сдаваться нельзя!

 

 

Если ПС база открытая - то было бы интересно поэкспериментировать, гипотетически. Лично мне это не надо, а досуга пока не предвидится для этой затеи. Но если время будет, то можно качнуть официальную версию бесплатную, если она еще существует.

 

Я так думаю, что сделать можно всё - вопрос, какой ценой.

Изменено 29 августа, 2011 пользователем Стекольщик — добрый и жадный

[Hirurg]

Ну можно взять БД от ПС - она не зашифрована. Там тоже есть ограничение на длину поля артикула.

Самое забавное, что и у нас подобный вопрос возникал недавно ... И повод был, кстати, похож ....

И ответ ...

 

И дело не в том, что нет желания и пр. А в том, как мне разъяснили программисты, что программу и БД из-за длины одного поля именно, что придется лопатить глубоко ...

И про быстродействие - не мои домыслы.

 

Раньше ходила такая легенда (а может и быль) что команда ПС или ее часть вышли (отделились) от КСТ. И начали развивать два отдельных продукта. С общими проблемами.

Как эта проблема решена в ПС? Есть ли там возможность отслеживать в автоматическом режиме форму а следовательно и себестоимость стеклопакета?

[Стекольщик — добрый и жадный]

И начали развивать два отдельных продукта. С общими проблемами.

 

Может быть. Также может быть, что на стадии проектирования были ошибки, а тут есть где ошибиться при таком объемном проекте, и от них избавиться теперь очень тяжело.

[viollan]

Не понятно почему затронуты всего две проблемы СО? Их гораздо больше. К примеру:

- При большом дереве профильных систем и фурнитур настройка превращается в "ад";

- Плоскостной оптимизатор отвратителен (им вредно пользоваться оч. плохое качество кроя даже для сэндвичей);

- Построитель: нельзя согнуть импост и поставить его на раму или др. импост, нет возможности выравнивать элементы конструкции (импост в 1 конструкции относительно импоста в другой, бывают случаи что расчитать положение достаточно сложно), нет возможности зеркального отображения элементов и т.д. и т.п;

- Нет возможности использовать 1 артикул как разный тип профиля например Т-створка (створка, импост) приходится изголятся в результаты проблемы со складами;

- Генератор отчетов очень слаб. (чтоб описать все его недостатки нужно заводить отдельную тему);

- У компаний которых более 5 ти пользователей работают с СО одновременно есть серьезные проблемы с БД;

- Закрытость БД для взаимодействия со сторонним ПО (про самоделки просьба не рассказывать сам страдал этим);

- Отсутствие в том же ТБМ (регионы) компетентных специалистов по СО. В приватной беседе ответили: дело ТБМ - это продавать фурнитуру, а программа это так промежду прочем и не понятно за что 5% от стоимости СО платит этому человеку;

- Склад очень примитивен. Нет элементарного НЗП (склад НеЗавершенного Производства);

- Безбумажка в СО хоть и есть но она очень скупа и не стоит тех денег.

Этот список неполон. Вывод один этот софт для небольших (очень небольших компаний) за большие деньги, видимо поэтому программа и называется СуперОкна

[Alber]

Айболит, человек, который отлично знает настройки Супер Окон. Я обращался к нему за помощью в настройке с/п в программе (тему настройки на этом форуме тоже я поднимал). Проблема для моей компании довольно серьезная. Результатом некорректной работы СО стали с/п на общую сумму 500тыс.р., которые просто вывезли за проходную для всеобщего растаскивания. А причина всего этого невозможность правильного вывода формулы стеклопкета. Для маленьких цехов это небольшая проблема. Один человек обычно и менеджер и логист и тех.задания он же. У него все в голове. А более крупным компаниям что делать. Есть фирмы в которых отдельно логист занимается только с/п. У нас проблема возникла, когда пришел новый логист. Ввиду запарки и нехватки времени, никто ей толком не объяснил как и чего, она и назаказывала как СО6 выдает. Пол-лимона на помойку. А проблемы с увеличением поля в БД я тоже особой не вижу. Работаю с БД очень давно. Начинал еще с dBASE на 16-разрядных компьютерах, потом Clipper, FOX. C Access сравнивать не буду он идет уже с оболочкой. Но обращение к БД стандартизировано языком SQL и я не думаю, что CO, написанные на Delphy, как то по другому работают с БД. Язык запросов не зависит от длины поля. Ради интереса скачал драйвер FireBird для ODBC. Спокойно открыл базу в Access, можно и в Excel открыть. Может, конечно, есть затруднения именно при шифровании и дешифровании, но это, ИМХО, не такой большой объем переделок. Видимо тут все гораздо проще. Зарезервирована возможность подзаработать за отдельную плату по индивидуальному запросу.

 

Не так все просто как кажется ....

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

 

Попробуйте определить процент пользователей, которых устраивают настройки с/п. И кому повредит увеличение длины поля?

Изменено 29 августа, 2011 пользователем Alber

[Стекольщик — добрый и жадный]

А проблемы с увеличением поля в БД я тоже особой не вижу....Язык запросов не зависит от длины поля.

 

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

 

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

 

Сначала через интербейс увеличить размер поля Артикул. Поле в СО ограничено, как стало известно, и ввести более 20 знаков не даст.

 

Т.к столбец известен, добавляем через СО новую запись, например, надо добавить сп формулу 6закSSSSB-18Ar-4-6закSSSSB, сначала вводим 20 первых знаков, потом оставшиеся еще в одну новую запись, т.е.

1. 6закSSSSB-18Ar-4-6з

2. акSSSSB

 

В таблице появятся 2 новые зашифрованные записи, например, такие:

1. hdksvujs754hd73hd734

2. h4uirhJ

 

Потом в табличную строку 1. записываем через интербейс

hdksvujs754hd734hd734h4uirhJ , т.е. (hdksvujs754hd73hd734)&(h4uirhJ)

а строку 2. стираем

 

Не знаю, верно или нет, попробывать бы.

 

Видимо тут все гораздо проще. Зарезервирована возможность подзаработать за отдельную плату по индивидуальному запросу.

Скорее всего. Может, лень, Может еще что. Но мне слабо верится, что это настолько ключевой момент, что придется лопатить всю программу. Меня подмывает уже на программном форуме этот вопрос выложить, может кто найдется там, причастный к СО.

Изменено 29 августа, 2011 пользователем Стекольщик — добрый и жадный

[Rexther]

Раньше ходила такая легенда (а может и быль) что команда ПС или ее часть вышли (отделились) от КСТ. И начали развивать два отдельных продукта. С общими проблемами.

Это не легенда. Начинали вместе, расстались ОЧЕНЬ давно. Ну как пример: я работаю с ПС начиная с 2-й версии, с 2011 года ... Т.е. к тому времени была уже во-первых 2-я версия и во-вторых продукт продавался.

Делайте выводы ...

На счет "общих проблем" ...

Я слабо знаком с СО - не было нужды пока. Но знаю, что программы имея много похожего идут разными путями по-сути.

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

Но в отдельной - я готов обсудить ПС и его функционал.

Как эта проблема решена в ПС? Есть ли там возможность отслеживать в автоматическом режиме форму а следовательно и себестоимость стеклопакета?

Не вижу вообще сложностей с организацией ценообразования в зависимости от формы пакета. Уже давно (много лет) это решено и есть возможности расширения функционала.

 

.....

Скорее всего. Может, лень, Может еще что. Но мне слабо верится, что это настолько ключевой момент, что придется лопатить всю программу. Меня подмывает уже на программном форуме этот вопрос выложить, может кто найдется там, причастный к СО.

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

 

Не понятно почему затронуты всего две проблемы СО? Их гораздо больше. К примеру:

......

Я бы почитал подобнвый список по ПС3.

 

.....

- Склад очень примитивен. Нет элементарного НЗП (склад НеЗавершенного Производства);

- Безбумажка в СО хоть и есть но она очень скупа и не стоит тех денег.

.....

НПЗ - что это? Можете пояснить?

И по безбумажке - хорошо бы подробнее ...

[Стекольщик — добрый и жадный]

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

 

Я тоже спорить совершенно несогласный. Просто задачка интересная и любопытная.

[viollan]

Я бы почитал подобнвый список по ПС3.

Ну так создайте соответствующую тему и услышите глас народа, чего вы со своим ПС в проблемы СО?

 

НПЗ - что это? Можете пояснить?

Вообщето я написал: Нет элементарного НЗП (склад НеЗавершенного Производства) т.е. материалы переданные на производство (материалы списанные/выданные со склада материалов), но не распределенные на ГП (готовая продукция). Если есть желание подробней, создаем новую тему и вперед.

 

И по безбумажке - хорошо бы подробнее ...

Без проблем, но ведь вы сами писали, что в функционале СО не сильны. Если же вы хотите узнать какой функционал на мой взгляд требуется от ПО по безбумажке, давайте сыграем в заказчика и поставщика ПО.

[Observer]

Привет!

 

.....

Я сделаю оговорку, что с форматом ДБ, используемым в СО я никогда не работал, и не представляю нюансы. А они нарисовываются так, что база зашифрована, и есть какие-то трудности, не позволяющие ручками через редактор внести длинный текст. Вникать до победного откровенно лень, я от СО далек.

..... СО не использует ничего, что не применимо к ANSI SQL 99. Сейчас 2011 год. Между прочим, "зашифрована" уже позволит любому ...... сделать предположение о неких структурированных данных, что плавно подносит к мысли к адресному чтению. А уж эта простая мысль объясняет, почему "перелопать большую часть программы" внезапно становится суровой реальностью.

 

Теперь второе и правильное:

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

Будет ли сделано когда-нибудь? Наверняка.

Когда? Как появятся ресурсы.

Что можно сделать? Ну, например оплатить эти работы? Эй, постойте, куда ж вы все...?

 

КСТ делает, что может. Есть ряд ограничений, в том числе связанных с текущей платформой.

Изменено 1 сентября, 2011 пользователем Rexther

[Observer]

.....

А проблемы с увеличением поля в БД я тоже особой не вижу. Работаю с БД очень давно. Начинал еще с dBASE на 16-разрядных компьютерах, потом Clipper, FOX. C Access сравнивать не буду он идет уже с оболочкой. Но обращение к БД стандартизировано языком SQL и я не думаю, что CO, написанные на Delphy, как то по другому работают с БД. Язык запросов не зависит от длины поля. Ради интереса скачал драйвер FireBird для ODBC. Спокойно открыл базу в Access, можно и в Excel открыть. Может, конечно, есть затруднения именно при шифровании и дешифровании, но это, ИМХО, не такой большой объем переделок. Видимо тут все гораздо проще. Зарезервирована возможность подзаработать за отдельную плату по индивидуальному запросу.

Так-так, продолжайте, коллега. Есл ине затруднит, а какую связь вы усматрвиаете между способом хранения и способом обработки? Ен приходило ли вам в голову, что длинна поля в БД - суть отражение длинны типа данных в ПО, а не наоборот?

Изменено 1 сентября, 2011 пользователем Rexther

[Стекольщик — добрый и жадный]

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

 

Вы скажите мне пожалуйста, я так понимаю, что компетентность позволяет, ответ на вопрос:

 

Если в базе длину поля Артикул изменить в большую сторону, затем внести запись длиной более 20 символов, а потом открыть СО, и посмотреть в какой л. форме или отчете вывод этого значения - что будет? СО повиснет, или просто отобразит это значение?

Изменено 31 августа, 2011 пользователем Стекольщик — добрый и жадный

[Observer]

Вы скажите мне пожалуйста, я так понимаю, что компетентность позволяет, ответ на вопрос:

 

Если в базе длину поля Артикул изменить в большую сторону, затем внести запись длиной более 20 символов, а потом открыть СО, и посмотреть в какой л. форме или отчете вывод этого значения - что будет? СО повиснет, или просто отобразит это значение?

В БД есть таблица, кажется - Artikles. В ней есть поля. Они являются только зеркалом того, с чем работает ПО. Поля же, которое коррелировало с внутренними структурами, в БД НЕТ. Вносить значение более 20 символов некуда. Если же распаковать in-memory object, и изменить его, то любое школоло, державшее в руках хотя бы Вирта, скажет, что будет невозможность распаковать объект. Ибо с т р у к т у р а. А, в случае ряда языков, еще и фиксированная структура. Конкретно СО выдаст что-нибудь типа "не удается прочесть настройки". Прочтите уже "Алгоритмы и структуры", а? Или погуглите "указатели ссылки чтение и запись памяти".

 

И все же: какой дурак вам вбил в голову, что БД диктует коду, а не код БД? Что вы к несчастному хранилищу, которое ни за что не отвечает, вообще прицепились такой толпой? Это вам Access прошлое нашептывает? Так ведь он был создан, чтобы даже дурак мог им пользоваться, со всеми полагающимися ограничениями, чтобы этот самый дурак себе в ногу не выпалил.

Изменено 1 сентября, 2011 пользователем Rexther

[Стекольщик — добрый и жадный]

Тогда отчего вы не работаете над собой?

Нет необходимости.

 

Вносить значение более 20 символов некуда.

Я конечно извиняюсь, а куда вносятся значения менее 20 символов? Насколько я понимаю, в СО я могу записать новый артикул, а потом указывать его в изделиях. Значит, этот новый артикул куда-то пишется, а потом и считывается. Может, ограничение в 20 символов есть только в поле ввода на форме - тогда его снять.

 

Если же распаковать in-memory object, и изменить его, то любое школоло, державшее в руках хотя бы Вирта, скажет, что будет невозможность распаковать объект. Ибо с т р у к т у р а. А, в случае ряда языков, еще и фиксированная структура. Конкретно СО выдаст что-нибудь типа "не удается прочесть настройки". Прочтите уже "Алгоритмы и структуры", а? Или погуглите "указатели ссылки чтение и запись памяти".

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

 

И все же: какой дурак вам вбил в голову, что БД диктует коду, а не код БД? Что вы к несчастному хранилищу, которое ни за что не отвечает, вообще прицепились такой толпой? Это вам Access прошлое нашептывает? Так ведь он был создан, чтобы даже дурак мог им пользоваться, со всеми полагающимися ограничениями, чтобы этот самый дурак себе в ногу не выпалил.

Да я как-то по наивности предполагал, что все базы примерно одинаковы по своей структуре, и способы внесения и считывания данных тоже не отличаются особой заковыристостью. Синтаксис запросов также особой оригинальностью не отличается (SELECT... FROM ...) к различным базам. Из баз работал только с акссесом и mysql, и как-то на их основе привык к тому, что у каждго стобца задаются свойства вводимых данных и их максимальные значения ограничиваются либо самим типом данных, либо принудительно. А код служит для манипуляций с этими данными.

Изменено 31 августа, 2011 пользователем Стекольщик — добрый и жадный

[Rexther]

Привет!

 

Первое и самое важное: все мною изложенное НЕ является официальной позицией КСТ софт, а только моим ЛИЧНЫМ мнением. Поэтому сдерживаться не стану (модераторы решат, когда нужно забанить) и буду писать так, как отвечал бы на профильном форуме.

....

Привет.

Не знаю знакомы ли ....

 

По поводу банов и прочего.

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

По поводу стиля общения: тут практически нет программистов. Только пользователи. По сути те самые инженеры ... Не все имеют высшее образование. Поэтому желательно попроще излагать - быстрее поймут и оценят.

 

 

P.S.S.: ПФ, по устным недокументированным заверениям сторон, базирует на утекших исходниках 3 версии СО. Гарантировать и ручаться не могу. Что услышал, то пересказал.

Как понимаю это тонкий вопрос .. весьма ... И лучше его тут, в отсутствии авторов, не обсуждать.

Изменено 1 сентября, 2011 пользователем Rexther

[Стекольщик — добрый и жадный]

Уже объяснил, в структуру. По смещениям. Это очевидно, если минуту подумать над фактом наличия шифранта в базе. Понимаете? Везде в ПО оно пишется и читается по смещениям. Каковых операций под тысячи. Следовательно, никакие копи-пасты, изменения в (ха-ха) субд проблему в лоб за разумное время не решают принципиально. Вы действительно не понимаете, какую чушь порете?

Нет, не понимал, пока Вы не объяснили.

 

 

Какое отношение базовые понятия работы с памятью имеют к вашей фразе о Delphi/Interbase? Или это отзвук "Нет необходимости."?

Нет, просто не понимал.

 

 

Вы очень наивны. Вы, кажется, взрослый человек, но с упорством семилетнего ребенка пытаетесь доказать взрослому человеку, что солнце плоское и его двигает по небу Мой Милый Пони.

Если вы внимательно прочтете мои посты Вам, то скорее там было больше вопросов, нежели чем утверждений.

 

Код служит для имплементации заложенной логики. Каковая может требовать манипуляции с данными, хранящимися где-то во внешней среде. Во главе угла - код. Никаких "этих данных" нет и не предвидится. В текущих системах базу руками несколько лет как не трогают, перестроение билдскриптами выполняется по объектной модели. Если требуется решение, ориентированное на скромные компьютеры регионов, то объектная система идет крахом, но storage все равно ничего никому не диктует.

Вот тут спасибо за ответ!!!

 

 

Скажите, что вы меня троллите, тонко шутите?

 

 

Немножко было

 

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

 

Маленькая хитрость была в том, что первый Ваш пост в данной теме содержит такой фрагмент:

 

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

 

Тут я подавился кофе. Теоретически, мы приматы. Практически, Homo Sapiens. Но если обращаться теоретически, не поймут модераторы. Так, простите, Учитель, оно таки сложно или таки очень Просто?

 

Эта моя фраза, как Вы заметили, действительно абсурдна. Это была обычная ловушка, нужна была лишь для того, чтобы "зацепить" внимание понимающего человека, который мимо такого безобразия точно не пройдет. Дальше построить диалог, и узнать то, что надо. Судя по ответу: Тут я подавился кофе. зацепило нормально. Ответ получен . Спасибо. Мой код сработал. Это Вам ответ на еще один Ваш вопрос:

 

Из чисто спортивного интереса напишите и выложите здесь, на форуме, свою реализацию тетриса. Нет времени? Ладно, удовлетворюсь примерами ваших патчей в любое OSS. Тоже нет? А что же тогда стимулирует вас нести бесстыдную чушь в прямом эфире?

Тетрис реализовывать не буду, но вы получили пример, как пропатчить мозг человека. Стимулировало желание получить ответ.

 

За отдельные хамоватые реплики - низачёд!

[FREE-LANCER]

Как было упомянуто для нас, простых смертных, что СО является объктно-ориентированной базой данных. А одной из характеристик таких ООБД, является ЦИТАТА под пунктом 3...

3.Поддержка инкапсуляции. Корректная инкапсуляция достигается за счет того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов. Конец цитаты

Исходя из этого понятно, почему так туго работает обратная связь с КСТ...

Ведь для того, чтобы что-то там поменять, нужна работа разных групп допуска..Если я не прав, сильно не ругайте, а просто попытайтесь тогда объяснить по возможности простым языком, понятным для пользователей, где собака зарыта в "СуперОперативности" обратной связи

Изменено 1 сентября, 2011 пользователем FREE-LANCER

[4UDO]

Немножко выскажусь. Я вот глянул сейчас ПС-2. Там в поле артикул разрешено использовать 115 символов. Однако же, есть поле название, длина которого впечатляет.

С СО не работал, но кажется мне, что такое же поле есть и там. Лично у меня забито порядка 20 различных видов заполнений. Название ни одного из них не умещается в поле артикул.

В итоге, для получения приемлемого результата лично я использую возможности генератора отчетов, поле "название" и различные комбинации вставок.

Если точнее, то стеклопакеты у меня отличаются только стеклами и рамками. Используется не так много: стекло 4,6, рамки 16,20,24мм. Этого вполне достаточно для того, чтобы существенно облегчить проектирование всего спектра алю. конструкций, за исключением фасадов. Над ними скоро планирую задуматься.

Но вот всего лишь такие вариации стекла и рамок позволяют получить массу вариантов. Почему? Потому что разнообразные пленки, закалка и прочее - это вставки.