|
Hi FoxProHater!
Здесь обычно обмениваются мнениями коллеги, и потому обращение на "ТЫ" не
является унизительным, скорее наоборот, но как ВАМ будет угодно...
> "Опытными программистами" с предустановленным "чувствительным очком", к
> сожалению, не всех сподобил господь рождаться сразу в готовом виде ... и
> только на собственном опыте учатся всему, что умеют или не умеют в этой
> жизни.
Где противоречие с тем что я сказал? Вы ЗНАЕТЕ про такие "странные"
ситуации - значит способны в 1001 раз не наступать на грабли. Думаю любому
нормальному человеку достаточно 1 раз понять свою ошибку, чтбы потом её не
повторять (ну а если вдруг кто запамятует и снова нарвётся, то исправит не
за неделю, а за 5 минут) - это относится к ЛЮБОЙ среде и ЛЮБОМУ языку.
> Особенно, если в публичных обсуждениях "достоинств" FoxPro последовательно
> скрывать свое знание о его реальных "недостатках".
1) Никто ничего не скрывает. Информация вполне доступна.
2) Вы говорили о недостатках NET? Приводили код на C# который "в 100 строк
содержит 5 глюков"? Так тогда кто из нас относится к вопросу ПРЕДВЗЯТО?
Дабы пресечь ваше закономерное "В NET ошибок нету" просто посоветую любому
заинтересованному лицу набрать в MSDN, в диалоге поиска слова "kbbug NET" и
посмотреть...
> А что, "статически описанные члены класса" в ООП уже стали добавляться в
> код класса через визуальный редактор форм
Естественно. По сути своей scx это и есть ОДИН класс (если откинуть объект
DE) - и если бы prg синтаксис не имел ограничений по вложенности, то данный
класс выглядел бы как
....
ADD OBJECT pf1.Page1 AS Page WITH ...
ADD OBJECT pf1.Page2 AS Page WITH ...
ADD OBJECT pf1.Page3 AS Page WITH ...
Это я и называю статическими членами класса.
Динамические - это добавленные в рантайме, посредством вызова метода
AddObject() (или NewObject()) - они вполне корректно удаляются с помощью
метода RemoveObject(). Статические же члены класса не могут быть удалены
столь безболезненно (в дизайнтайме они ВООБЩЕ не могут быть удалены - и это
тоже вполне закономерно).
Из "недокументированных" особенностей стоит отметить пожалуй то, что даже
просто указание pf1.PageCount=3 в ОПИСАНИИ класса (а не где-то там в
pf1.Init() или ещё каком методе - т.е. в рантайме) создаёт статические члены
класса.
> при явном удалении объекта из контейнера никаких "хвостов" от этого
> объекта оставаться в контейнере не должно (азбучная истина).
Если вы вырываете зуб - то следов никаких не остаётся?
Почему вы считаете, что фоксовый контейнер это исключительно динамическая
сущность? Это далеко не так - фоксовый контейнер (PageFrame в частности)
может сочетать в себе как динамические, так и статические элементы. Если его
НЕ наполнять ничем в DesignTime - то ВСЕ элементы будут динамическими.
> Может быть и знаю, но к теме обсуждения это отношения не имеет, т.к. я не
> мембера выкидываю из класса, а объектную ссылку из коллекции контейнера.
Нет, вы именно member-объект пытаетесь удалить. Это НЕ ссылка в коллекции.
> Мне ошибка не нужна, я именно это и хочу учесть при обращении в странице,
> которая потенциально может быть удалена из PageFrame
Тогда вам не стоило Page описывать статически - нужно было в Init фрейма
добавить свою страницу (либо по AddObject, либо увеличив PageCount).
В приведенном же случае может помочь скажем type("this.pf1.Page3.Name") =
"C". Однако повторюсь - ошибка не тут, а в самой первоначальной идее -
пытаться удалить статический member-объект...
> Я не могу понять, почему "Visible = .F. при AddObject борется с Visible =
> .T.", зачем им "бороться"? Это что - 2 "конкурирующих" Visible?
Нет, но это взаимно противоречащие установки для одного и того-же свойства
(т.е. фокс полагает то что контрол добавленный по AddObject()невидим, а по
факту он видим). Я не могу сказать точно каков порядок инстанциации контрола
в данном случае, но видимо Visible = .T. в определении срабатывает до того,
как проинициализируются внутренние свойства, определяющие расположение
контрола на невидимой странице (и как следствие контрол НЕ должен
прорисовываться).
> И почему для FoxPro-шных контролов (Grid, TextBox etc) никакой "борьбы" не
> наблюдается
Поскольку они "рисуются" в отличие от Activex-а, и видимо не имеет значения,
будет ли произведено "несвоевременое" отображение или нет.
> Или это специальное мощное средство FoxPro для "облегчения использования"
> ActiveX-компонентов?
Конечно нет - это конечно непредусмотренный эффект - видимо тестеры не
додумались сделать такую комбинацию свойств, и пропустили...
> Настолько же часто, насколько любой программист захочет написать
> добавление грида на форму кодом, а не форм-дизайнером.
Я не очень представляю ситуацию, когда нужно ОСТАВИТЬ RecordSource пустым -
т.е. если добавить программно грид, и присвоить RecordSource, то никакой
проблемы не будет... Если же ИМЕННО надо оставить это свойство пустым -
считайте число колонок другим способом, например через AMEMBERS() или при
описании класса грида явно укажите ColumnCount=0 (раз уж колонки добавляются
через метод AddColumn()). Вообще ColumnCount = -1 это специально
зарезервированное зачение (для поддержки автосоздания столбцов) - видимо
потому и обработка сделана как-то по особому, и возникает в результате
описанная вами проблема.
>> - а допустим ли ТАКОЙ синтаксис в SELECT команде? не нужно ли убрать
>> первый строковый литерал?
> Такой вопрос открывает в тебе "большого специалиста" по
> клиент-серверным технологиям ввообще и по T-SQL в частности, лучше бы
> сразу признался: "извините, не работал я с MS-SQL-Server, все под DBF-ками
> точу", не позорился бы лишний раз.
Я просто не могу проверить это, "пощупать своими руками" так сказать - о чём
и предупредил. У меня стоит Oracle, в нём естественно такой синтаксис
недопустим. В синтаксически корректной конструкции, например:
? SQLEXEC(ln1, "begin RAISE_APPLICATION_ERROR(-20001, 'Мой текст сообщения
об ошибке'); end;")
Всё возвращается как и положено - именно пользовательское сообщение об
ошибке. Аналогично (корректно) отрабатывают и ошибки генерируемые из UDF,
пакетов и т.п.
Я специально посмотрел BOL, и не нашёл там нигде подобного примера
(RAISERROR везде употребляется вне SELECT - как отдельная команда) -
упоминания о том, что RAISERROR можно использовать внутри SELECT я также не
обнаружил. Кроме того, согласно общему синтаксису команды SELECT, между
элементами списка выбора должны быть запятые. Только в случае
"элемент_выбора [AS] название_поля_в_резалтсете" не нужно запятых - но как
может быть "названием поля" такая конструкция - я не представляю.
Если же вы имели в виду что это 2 отдельные команды, то видимо между ними
нужно добавить символ ; - как описано в статье "Specifying Batches"
для ODBC.
> Еще один образец понимания сути команд на языке T-SQL (а командишка-то
> плевая, всего 2 простейших оператора).
Так это одна команда, или всё-же Batch из 2-х команд? Я не привык к тому,
что разные команды ничем друг от друга не отделены, и не уверен что ODBC
может корректно обработать такую строку...
> И тут "прокольчик"
Вопрос в том чей - мой или ваш. Ибо по поводу RAISERROR в BOL написано
довольно много - в частности (если очень кратко) - для батчей возвращающих
несколько резалтсетов нужно проверять статус наличия ошибки после получения
каждого резалтсета - ибо последующие резалтсеты будут затирать результаты
предыдущих. В фоксе, чтобы раздельно получать множественные ODBC резалтсеты,
нужно как минимум отключить "BatchMode" и воспользоваться SQLMORERESULTS().
Является ли конструкция из одного единственного SELECT и последующего
RAISERROR "многорезультатной" я не могу сказать.
, ув. "большевик" - как раз "ДРУГИЕ клиенты работающие через ODBC драйвер"
обрабатывают это ситуацию "на ура" (
> например, тот же ADODB.Recordset
Вообще-то ADODB обычно работает не с ODBC драйвером, а непосредственно с Ole
DB провайдером.
> но я-то писал не о "других", а о твоих "родных", FoxPro-шных
О ком это? ODBC такая-же сторонняя система для VFP как и OLE DB и ADO.
"Родное" для него это прямой доступ к dbf и ничего более.
> а ты тут берешь и прямо открытым текстом расписываешься в том, что ничего
> другого и не знаешь...
Да, в MS SQL я не являюсь специалистом. Однако мне кажется, что это не имеет
никакого отношения к теме разговора.
> есть разница между "детскими болезнями роста" и "старческими болезнями
> вырождения", и не чувствовать ее может только слепой/глухой...
Видимо я такой и есть, ибо для меня ошибка - она и есть ошибка - независимо
от того существует она в VFP, в .NET или в любой другой программе. И почему
ошибки в NET это "ничего страшного" а ошибки в VFP это причина называть его
всякими обидными словами - я не понимаю.
Я ещё могу понять классификацию ошибок по степени их влияния на процесс
разработки - т.е. на критические (нет возможности их обойти и потому
использование какой-то функции/класса/просто элемента языка невозможно) и
некритические (когда способ обхода известен и не представляет никакой
проблемы).
Posted via ActualForum NNTP Server 1.2
|
