2 Igor Korolyov

Цитата:

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

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

Цитата:

Нет, меня не радует всё о чём ты говоришь, но я готов с этим мирится, ибо
это всё не так уж и существенно

Цитата:

вот ТАК ли это актуально и
насущно - вот в чём вопрос.

Все это резко становится актуальным и насущным, когда возникают задачи, вроде на первый взгляд простые, но отклоняющиеся от продполагаемого MS прямолинейного использования контролов. К примеру "как запретить разворот Combo?", либо "как отловить его сворачивание?" или "как программно развернуть?". Все это на фоксе решается извратами - а ведь если бы комбо в фоксе было бы полноценным окном, то, например, последний вопрос имел бы банальнейшее решение - посылка сообщения CB_SHOWDROPDOWN окну комбо. Во избежание дальнейших кривотолков, я еще раз уточняю свою позицию. Не о разноцветных ячейках в гридах я говорю. Любая нестандартная задача на уровне контролов, пришедшая в голову программисту в Дельфи, Си или VB потенциально решаема посредством работы с сообщениями окна контрола, и привлечением для этого встроенных и апишных средств. В фоксе мало того, что поятия "окно" в случае контрола не существует, что отсекает целый пласт апишных средств, так еще и функционала для контроля за процессом внутренней, Фоксовско-реализованной жизни такого псевдо-окна нет (например, как Canvas у контролов в том же Delphi, как VCL'овская обертка вокруг системы оконных сообщений). Если Дельфисту что-то надо, чего нет во встроенной реализации контрола в VCL-библиотеке, он сам возьмет и напишет, поскольку внутренняя реализация архитектуры контролов в среде Delphi ему предоставляет для этого все возможности! Фоксист же будет ждать 8-ю, 9-ю, 10-ю, n-цаттую версию своей среды, где за него это сделает MS (если захочет). И не потому что он такой ленивый, а потому что в среде просто возможностей для этих вещей нет - авторы VFP не заложили! Вот в чем принципиальная разница...

Цитата:

Насчёт фоксовых контролов. Ты смотришь в своей перспективе - не учитывая,
что для MS одно из ВАЖНЕЙШИХ требования в отношении фокса было, есть и будет
обратная совместимость. От того и невозможно перейти на другие контролы. Ибо
моментально рухнет 99% существующих программ.

Совершенно не понятно что тут может рухнуть, если PEMs контролов не изменится. Просто MS надо было бы аккуратно этот переход делать и тщательно тестировать. На платформу Win32 из ДОСа значит можно было @SAY/GET перетащить, а реализацию контролов на базу comctl32 нельзя? Принципиальная разница между этими двумя вещами где? Я не вижу... Поэтому ответ "не нашли на это время" я понимаю, но "невозможно перейти" - не понимаю, извиняйте... Делать конечно это надо было раньше, сразу после VFP3, сейчас уже поздно... во всех отношениях

Цитата:

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

Судя по твоей реплике можно предположить, что я тут ору на весь свет: "Бросайте все к чертям фокс, да здравствует великий Дельфи/Васик/Дотнет/<нужное вставить>" . Суть же того, о чем я говорю, не в этом, а в том, что та ситуация, которую мы в современном фоксе имеем, с контролами 1995-го года розлива - суть закономерное следствие выбранной майкрософтом архитектуры VFP в этой области. И куча кода рекордсето-основанных языков для локальной обработки данных тут совсем не при чем. Речь ведь не о том совсем

Цитата:

Цитата:

Почему хэдеры грида при активированных темах XP, при пронесении над
ними мыши должны перекрывать (навсегда (!)) по Z-order'у все что было
раньше над ними. Почему такого поведения нет при отсутствии
тем?

AFAIK есть в VFP7 и раньше - т.е. это пофиксили, но не до конца В более
ранних просто при активации грида, и при некоторых других условиях хедеры
грида перерисовывались "поверх всего". Если не помнишь - посмотри код из
SortGridSample - там здоровенная часть посвящена именно выводу индикатора
"поверх" хедера (точнее не выводу, а "удержанию" его там - чтоб он ПОД хедер
не падал).

Это не совсем то. Описанное поведение я наблюдаю в VFP8-9 при активированных темах WinXP. Положи поверх хэдера Image, активируй тему и поводи мышкой над заголовком. Тема будет "подсвечивать" хэдер и при этом подсветка будет перекрывать все, что расположено по Z-order'у над хэдером - и наш Image тоже. Насчет перекрывает навсегда - это я в прошлом посте погорячился, не навсегда, а на момент подсветки, но тоже мало приятного

Цитата:

Цитата:

Почему поддержку тем XP все разумное человечество делало банальными
файлами-манифестами, а мы ждали когда MS закончит VFP8?

Ты бы ещё вспомнил про MS Treeview версии 6. Это кстати не на фоксе сделано
было, а проблемы точно такие-же (и причины кстати тоже)!

Не совсем, если честно, понял, к чему это... Ну вот решили в MS так облегчить Васечникам дистрибуцию приложений - пару dll'лек так отсекли... надо это было? ИМХО наибредовейшее решение - теперь сами же васечники на форумах за это MS и матерят. Избавление от необходимости такскать несколько dll'лек вылилось теперь в принципиальное отутствие поддержки тем XP всеми контролами mscomctl, и не лечится это никак. Стоило ли оно того? А вместе с Васечниками попали и мы, поскольку и для нас это стандартный контрол...

Цитата:

И вообще если уж переписывать
фокс, то переписывать его как .NET язык - со всеми вытекающими.

Полностью и 100%-но тебя поддерживаю, но похоже не дождемся...



[i][small][color=Gray]Отредактировано (23.11.04 15:11)

2 urfin
Теперь понятно! Это не Grid вовсе...

2 Igor Korolyov

Цитата:

Кстати в связи с постоянным расширением средств манипулирования данными на стороне
клиента в .NET это уже не выглядит так "невозможно" как было в момент
появления .NET

Это совсем не понятно, можно подробней?

Оживить Фокс можно только слиянием с NET - это понятно.
И NET это не зло, это мост между языками, а мы остаемся на необитаемом острове
и нас все меньше

Цитата:

От того и невозможно перейти на другие контролы. Ибо
моментально рухнет 99% существующих программ.

Почему рухнет? Будут существовать себе в своем рантайме...
Я вот когда переходил с FP2 на VFP5 пытался прогу запускать,
в итоге добился - заработало, но как это выглядело вспоминать не хочется...
И оставил эту затею...
А формы все еще поддерживают READ интерфейс, зачем?
Взять наш форум: кто нибудь в 2004 году просил помочь решить проблемы
с READ в Фоксе 5 или 6 например? Ответ понятен...
В чем смысл переводить прогу на новую версию языка, если она использует только старые конструкции?
Например уже во 2-м Фоксе правктически не использовались dbase-команды,
а зачем они сейчас нужны? Это уже не поддерка обратной совместимости,
это фигня какая-то - наверное никому за те учаски кода и браться просто не хочется...

Hi, urfin!

Цитата:

Кстати Size grip таки можно заставить появиться... как в тулбаре
оутглюк экспресса

ГДЕ? Я там ничего такого не вижу

Цитата:

огласите весь список, пжалста

Нету там никакого списка. Там исключительно .NET и ничего больше...

Hi, Aijik!

Задачи есть разные. Поверь, мне - твоё желание иметь сложный хедер это лишь
одно из миллиона - мне например это совершенно не нужно было, а вот кой
какие другие - скажем объединить вертикально группу полей (скажем для каждых
5-ти записей) - нужны позарез! Не от хорошей жизни я кое где использую MS
FlexGrid - и с его прибабахами приходится мириться
Насчёт продвинутых возможностей Delphi/C++ и иже с ними - чесслово, не видел
ни одного программера, который переписывал бы компонент "под себя", хотя
возможности такие действительно есть! Обычно всё сводится к поиску "другого"
набора компонент, лихорадочному переписывания интерфейса с старых на новые,
потом радостном показе клиенту - ну а через некоторое время, как тока
проявляются очередные глюки или ограничения этого набора - всё повторяется
сначала...

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

Цитата:

Совершенно не понятно что тут может рухнуть

Popup меню как источник данных для комбо с цветными элементами, те-же
SAY/GET и их элементы в текстбоксах (ну там Format хитрый или InputMask). В
общем очень много таких мелочей, которые крайне сложно перевести (и 100% что
это не будет просто win-контрол - это будет свой субкласс а значит опять
масса ограничений и нехороших "фишек")...
И ты совершенно прав в том, что это надо было делать ещё при разработке
VFP5 - но ТОГДА требования совместимости были ЗНАЧИТЕЛЬНО более
приоритетными чем сегодня - продукт просто не был бы востребован - ну "ещё
один VB подобный язык"... Даже тогда MS пропихивал кривой и убогий VB куда
как интенсивнее чем значительно превосходящий его практически во всём VFP

>> Кстати Size grip таки можно заставить появиться... как в тулбаре
>> оутглюк экспресса

> ГДЕ? Я там ничего такого не вижу

Извиняюсь, ... как в статусбаре IE.

Вообще, есть ли способы показать grip без Form.ScrollBars=3 и переполненной формы ?
А для базового класса TollBar (он же тоже форма) ?
Кстати зачем он форма ? (Если он форма для формсета, то где у него DataEnvironment )
Первое что я хотел сделать, знакомясь с VFP5 - это кинуть ToolBar на форму и обломался
IMHO - неправильно это, неинтутивно понятно. Вааще не понятно для нормального человека
IMHO, то что фоксовый тулбар не умеет жить в IntopLevel форме (только в Screen и TopLevel) - тоже неправильно.
Поскольку при построении приложения, типа TopLevel форма + куча IntopLevel форм в ней, приходится
ограничиваться тулбарами только в главном окне. В подчиненных формах - приходится их криво эмулировать.
Почему я не имею права создать IntopLevel форму с меню ?
Не вижу причин для подобных ограничений функциональности IntopLevel формы.
Дайте контрол, не получающий фокус, а я уж сам найду что туда засунуть.
И вааще, изначально, в языке должен быть один класс - Empty
Или например, хорошим тоном считается, унаследовать все базовые классы и далее плясать от их потомков.
Ладушки - как умная Маша - наследую базовый Control в myControl. Все приплыли. При попытке добавить
из среды элемент управления в наследника, получаем : "Cannot add objects to a class based on control class".
Если базовый класс Custom - это контейнерный класс, то почему не дали возможности набросать в него
невизуальных контролов прямо в среде разработки ? Или 2 раза шмякнуть по брошенному на форму классу
DataEnvironment и чтоб запустился DataEnvironment Designer.
Думаю большенство начинающих сталкиваются с подобными непонятками.
А про контролы - полноценные окна - адабрямс
Только не слышат власть придержащие.



[i][small][color=Gray]Отредактировано (24.11.04 07:54)

Кстати, форум регулярно посещает Aleksey Tsingauz - Visual FoxPro Dev Team.
Надеюсь он прислушается к нашим бедам и пролоббирует интересы простых девелоперов.

Hi, Виктор!

Цитата:

Извиняюсь, ... как в статусбаре IE.

А - ну это совсем другое дело Он и в статусбаре фокса есть (в штатном), и
наверняка можно в ActiveX-овом статусбаре его сделать.

Цитата:

Вообще, есть ли способы показать grip без Form.ScrollBars=3 и
переполненной формы

Наверное если поместить статусбар в форму Я кстати вот так с ходу нигде
(ни в одном приложении) его не видел не в статусбаре - в том-же IE
убираешь статусбар - пропадает и этот объект

Цитата:

А для базового класса TollBar (он же тоже форма)

А для тулбара я его ВООБЩЕ нигде не видел (даже в навороченном в плане UI
Office2003). И слабо представляю зачем он там может понадобиться - ресайз и
так работает, если за уголок тягать, а что "труднее попасть" - ну не каждый
день я тулбары меняю в размерах Я их в принципе не меняю в размерах, ибо
они обычно задоканы, а в таком виде вообще ни о каком ресайзе речи не идёт
(даже в других средах. Не путать тулбар с Docable формой!).

Цитата:

Кстати зачем он форма

Он НЕ форма. Он окно (в смысле винды),
он присутствует в коллекции _SCREEN.Forms, но он отдельный, совершенно
особый объект VFP.

Цитата:

Если он форма для формсета, то где у него DataEnvironment

Если объект (и форма и тулбар) находится в Formset, то они используют DE (и
соответственно DS) формсета. Если ты про визуальный редактор и про ОБЪЕКТ
DE - то они существуют лишь в scx формах - в классах их просто нету, что
впрочем не значит что нельзя соединить класс DE с классом формы или тулбара
(программно конечно). Михаил Дроздов буквально на днях ещё раз довольно
подробно это расписывал в fido7.ru.visual.foxpro

Цитата:

Первое что я хотел сделать, знакомясь с VFP5 - это кинуть ToolBar на
форму и обломался IMHO - неправильно это, неинтутивно понятно.

Ты хотел сказать интуитивно непонятно
Я придерживаюсь другого мнения. Toolbar - это отдельный объект, он может
существовать и совсем без формы, а может и для нескольких форм один
использоваться. Потому решение MS мне кажется вполне оправданным. А вот для
того что желаешь ты, я сделал особый объект - так называемый функциональный
объект (act) - это производный от custom класс, и его МОЖНО (и нужно)
"кинуть" на форму - а он при инициализации создаёт (или использует уже
созданный ранее) объект класса Toolbar - соответственно Click на элементах
Toolbar-а вызывает методы этого объекта. А заодно эти-же методы можно
вызвать и из меню, и по хоткею и вообще как угодно.
А если тебе не нравится такой вариант - просто кинь на форму CommandGroup -
это и будет твой "тулбар на форме".

Цитата:

то что фоксовый тулбар не умеет жить в IntopLevel форме (только в
Screen и TopLevel) - тоже
неправильно

Он может, но очень криво. Я совершенно согласен что это неправильно - думал
может в VFP9 изменят, но увы...

Цитата:

приходится ограничиваться тулбарами только в главном окне

Приходится. Хотя с другой стороны это вопрос стиля - меня например не сильно
радуют интерфейсы, где на КАЖДОЙ форме свой тулбар - откроешь так с десяток
форм, и аж в глазах рябит В классическом MDI интерфейсе MS офиса подход
мне нравится значительно больше - один и тот-же тулбар работает со всеми
окнами. В новом же режиме (с отдельными кнопками для каждого документа на
таскбаре) по сути эмулируется наличие кучи отдельных экземпляров ворда...

Цитата:

В подчиненных формах - приходится их криво эмулировать

Зачем криво Эмулируй прямо! Лучше чем имеющиеся! и Size Grip свой
вставляй, если конечно он тебе нужен в тулбаре...

Цитата:

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

Это ограничение винды на самом деле. Из MSDN:

Цитата:

Дайте контрол, не получающий фокус, а я уж сам найду что туда
засунуть

Label, Image - рисуй например в Image кнопки, и анализируй позицию нажатия
(заодно и крутая настройка для юзера - почти что скин )

Цитата:

И вааще, изначально, в языке должен быть один класс - Empty

Не, не Empty (это как раз особый случай), а Object - с методами
Init/Destroy/Error и свойствами Name/Class... СОГЛАСЕН, что порой сильно не
хватает такого "фундаментального" объекта - приходится убогим Copy'n'Paste
заниматься

Цитата:

наследую базовый Control в myControl. Все приплыли

Он вообще очень странный контрол IMHO. Там проблемы будут и есть скажем в
него кинуть мощно субклассированный контрол - он очень странно видит
методы - через один уровень
Ну т.е. если есть иерархия CommandButton - cmd - cmdSome - cmdCool -
cmdSuperCool и вот этот последний запихать в Control, то вылазят глюки при
вызове кода из класса cmdCool, и возможно cmd - причём ИЗ САМОГО ЭТОГО
Member-объекта. В общем я им (классом Control) предпочитаю не пользоваться
вообще

Цитата:

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

Глюк дизайнера классов. Программно то без проблем

Цитата:

Или 2 раза шмякнуть по брошенному на форму классу DataEnvironment и
чтоб запустился DataEnvironment Designer

Не пользуюсь классами DE - тока объектами (теми что в scx формах
есть).

Цитата:

Думаю большенство начинающих сталкиваются с подобными
непонятками

Возможно. Но таких непоняток хватает в ЛЮБОЙ среде программирования. Мы не
одиноки

Я хочу про 3 d grid
Конечно это не все , про что тут говорили
Однако делала пару раз так
1 для визуального эффекта
Грид внутри контрола
Контролу specialeffect -raised
В init контрола координаты грида по топ лефт на -1
на высоту и длину на 1 больше контрола
Высота ячеек грида увеличивается пока не станут видны границы текстовых коробок
2 для просмотра внутри ячейки данных в 3 ем измерении как в flexgrid
тоже разрабатывал контрол из текстовой коробки и грида
Коробка видна пока на ячейке с таким контролом нет фокуса, как только есть, высота колонки грида увеличивалась ( к сожалению для всех строк) и показывался грид, в котором дочерняя таблица или что там нужно в 3 измерении. Как фокус такая ячейка потеряла, высота колонки -старая и показывается снова текстовая коробка
Почему спросите не flexgrid
Потому что для заказчика делалось , к которому доступа нет, он в другом городе.
Как только активикс, так работа с таким заказчиком может иметь потенциально проблемы ( а может и не иметь), поэтому и сделал самодельный грид
Недостатки помимо одной высоты всех рядов
Поскольку оба грида внутри контролов , приходится делать методы доступа для колонок и текстовых коробок, так как снаружи их в контроле их свойства не видны

Hi, Игорь!

> Наверное если поместить статусбар в форму.

ActivX - без поддержки XP тем. Хочу нативный StatusBar и TreeView,
ведь Grid же дали, а могли и броузом ограничить и про FlexGrid напомнить

> А для тулбара я его ВООБЩЕ нигде не видел (даже в навороченном в плане UI
> Office2003). И слабо представляю зачем он там может понадобиться ...

Я из него статусбар делаю.

> Я их в принципе не меняю в размерах, ибо они обычно задоканы ...

Аналогично.

> Он НЕ форма. Он окно (в смысле винды),

Но не полноценное окно в смысле виндов

> он присутствует в коллекции _SCREEN.Forms, но он отдельный, совершенно особый объект VFP.

Хочется меньше особенностей и большей интуитивнопонятностей

> Если объект (и форма и тулбар) находится в Formset, то они используют DE ...

FormSet, SET PROC, PUBL, BROW, DEFI/ACTI WIND IN, SAY/GET, эм с точкой и т.п. анахронизмы стараюсь не пользовать.

> Я придерживаюсь другого мнения. Toolbar - это отдельный объект, он может
> существовать и совсем без формы, а может и для нескольких форм один
> использоваться. Потому решение MS мне кажется вполне оправданным.

Я прошу от разработчиков визуальный контейнерный класс -
контролы которого не получают фокус (как у ToolBar).
Тогда и нативный тулбар в IntopLevelForme не нужен.

> Он может, но очень криво. Я совершенно согласен что это неправильно - думал
> может в VFP9 изменят, но увы... приходится ограничиваться тулбарами только в главном окне

Консенсус.

> Приходится. Хотя с другой стороны это вопрос стиля - меня например не сильно
> радуют интерфейсы, где на КАЖДОЙ форме свой тулбар - откроешь так с десяток
> форм, и аж в глазах рябит В классическом MDI интерфейсе MS офиса подход
> мне нравится значительно больше - один и тот-же тулбар работает со всеми окнами.

Ну дык, мы не офисы пишем. В любой форме может быть стандартная, часто используемая операция,
характерная ТОЛЬКО для этой формы. Вот тут ToolBar в Intop очень бы пригодилcя. Потеря фокуса - обескураживает.

> Это ограничение винды на самом деле. Из MSDN:
> Only an overlapped or pop-up window can contain a menu bar; a child window cannot contain one

Ну и пусть это меню (в Intop) не будет реагировать на HotKeys (а только меню в TopLevelForm)
- дайте возможность вообще его задефайнить типа DEFI MENU ... IN WindowName,
ан нет : This clause is supported only in top-level forms which can be set with ShowWindow=2 or Desktop=.T.

Кстати в VFP9Beta, формы докаются только в IN SCREEN
(FormShowWindow property set to 0) - это тоже совершенно дикое ограничение.
Хочу TopLevel форму докать на десктопе - как в WinAmp.

>> Дайте контрол, не получающий фокус, а я уж сам найду что туда засунуть
> Label, Image - рисуй например в Image кнопки, и анализируй позицию нажатия

Вот это я называю неоправданным извратом. Cколько кода ушло в мусор с появлением
якорей, картинок в хэадерах и всплывающих кнопок ?

>> И вааще, изначально, в языке должен быть один класс - Empty

> Не, не Empty (это как раз особый случай), а Object - с методами
>Init/Destroy/Error и свойствами Name/Class...

Адабрямс. Красиво.

>> наследую базовый Control в myControl. Все приплыли

> Он вообще очень странный контрол IMHO.
> ...
> В общем я им (классом Control) предпочитаю не пользоваться вообще.

Да, очень похоже, что разработчики о нем забыли (в VFP9Beta - якоря не пашут)
А жаль, задумка красивая и правильная ...

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

> Глюк дизайнера классов. Программно то без проблем

IMHO недоработка это.

>> Или 2 раза шмякнуть по брошенному на форму классу DataEnvironment и
>> чтоб запустился DataEnvironment Designer

> Не пользуюсь классами DE - тока объектами (теми что в scx формах есть).

Я тоже, но было бы красиво. Поскольку в VCX форме DataEnvironment Designer отсутствует.

> Возможно. Но таких непоняток хватает в ЛЮБОЙ среде программирования. Мы не одиноки.

И это не может не радовать

P.S. Дедушка мороз, подари мне на новый год RTF Report Listener

Hi, Виктор!

Цитата:

ActivX - без поддержки XP тем

Смотря какая версия. Правда там глюк на глюке, и grip он не рисует, и мусор
на экране остаётся, в общем .....

Цитата:

Я из него статусбар делаю

И спрашивается кто тебе в этом виноват

Цитата:

Но не полноценное окно в смысле виндов

Полноценное.

Цитата:

FormSet, SET PROC, PUBL, BROW, DEFI/ACTI WIND IN, SAY/GET, эм с
точкой и т.п. анахронизмы стараюсь не пользовать.

Без SET PROC ты как обходишься то? Или UDF для тебя тоже табу? И в чём
виновато m. ? IMHO БЕЗ этого программа становится потенциально небезопасной.
И так будет до тех пор, пока приоритет при обращении будет у поля текущей
таблицы.

Цитата:

В любой форме может быть стандартная, часто используемая операция,
характерная ТОЛЬКО для этой формы. Вот тут ToolBar в Intop очень бы
пригодилcя. Потеря фокуса - обескураживает.

Если у тебя есть обычный
тулбар (размещённый сверху главного окна например), и ты ещё и в форму
запихаешь один - это будет IMHO очень некрасиво - сильно много ненужных
дёрганий мышой. Контроля должны быть по возможности рядом друг с другом, а
не раскиданными по экрану. Есть лишь очень немного исключений из такого
правила.
Кстати - я при работе из тулбара СПЕЦИАЛЬНО увожу фокус с текущего конторла
на некоторый фиктивный - ибо БЕЗ этого введённые в контрол данные никуда не
запишутся, и будет очень нехорошо

Цитата:

Ну и пусть это меню (в Intop) не будет реагировать на HotKeys

Где-нить в Init формы:
Криво, убого, некрасиво? Но как оно может быть иначе, если принять во
внимание что винда НЕ МОЖЕТ такие меню создавать. В ПРИНЦИПЕ! А фокс как
умеет так и делает.

Цитата:

Кстати в VFP9Beta, формы докаются только в IN SCREEN

Я в курсе. Да, плохо что оно так - значится на аналог Panels это не
годится...

Цитата:

Хочу TopLevel форму докать на десктопе - как в WinAmp.

А разве он докается? Там вроде просто окна друг к другу "прилипают", и если
близко к краю подтянуть, то окно к этому краю "прилипает". С Dockable это не
имеет ничего общего, и кстати реализуется в фоксе элементарно - буквально 5
строк кода вызываемых из Moved и Resize. Я помнится как-то пример рисовал -
на 2 "слипшиеся" формы - для "прилипания" к границам десктопа по сути
аналогично будет - главное расстояние "притяжения" выбрать нормально.

Цитата:

Вот это я называю неоправданным извратом

Т.е. тулбар вместо статусбара нормально, а "рисованный" тулбар изврат?
Видимо разработчики того-же WinAMP, да и Windows MediaPlayer сплошь
извращенцы
Зря ты так сразу отвергаешь - это же супер круто получается. Какие-там к
лешему разноцветные гриды, мы интерфейс a-la WinAMP на фоксе нарисуем

Hi, Игорь!

Спасибо за обсуждение интерфейсных проблем.

Бум думать ... Особенно про меню AT LINE 0.039 ... На безрыбье и раком станешь

Вместо SET PROC у меня несколько Custom классов с UDF методами, например :
goApp.Library.WinAPI.Sleep()
goApp.Library.Function.PixelToFoxel().

Эм с точкой не нужен если строго следовать Naming Conventions от Microsoft.

Про "ToolBar - не полноценное окно в смысле виндов" это я конечно чушь спорол.

Про различие доканья и прилипания - тонко подмечено.

Цитата:

Я при работе из тулбара СПЕЦИАЛЬНО увожу фокус с текущего конторла
на некоторый фиктивный - ибо БЕЗ этого введённые в контрол данные никуда не
запишутся, и будет очень нехорошо.

Я поступил иначе. В методе MyEditForm.SaveDateAndExit() пишу :

IF TYPE('This.ActiveControl') = 'O' AND PEMSTATUS(This.ActiveControl, 'Value', 5)
This.ActiveControl.Value = This.ActiveControl.Value
ENDIF

Эффект тотже. Введённые в контрол данные сохраняются перед TABLEUPDATE(),
но отпадает необходимость в фиктивном контроле.

Цитата:

мы интерфейс a-la WinAMP на фоксе нарисуем

Нееее ... DOOM4, Half Life3, Unreal 2k5, Duke Nuken Forever 2

Удачи.



[i][small][color=Gray]Отредактировано (26.11.04 12:27)

Вспомнил очередную старинную непонятку :

Применение SET ORDER не приводит к изменению свойства THISFORM.DATAENVIRONMENT.CURSOR1.ORDER
А вот изменение THISFORM.DATAENVIRONMENT.CURSOR1.ORDER приводит к изменению SET('ORDER')
Недопеченое оно что ли ? Спасибо, что хоть OrderDirection добавили.

И еще, хорошо бы поиметь свойство у Exception, равное ссылке на объект, вызвавший Exception.
Или нечто подобное, а то при глобальном TRY ... READ EVENTS ... CATCH,
имя процедуры с ошибкой (Exception.Procedure) и уровень стека ошибки (Exception.StackLevel) известены,
а отследить цепочку вызова невозможно. Опять недожарили ?

Добрый дедушка Мороз, подари мне на новый год лошадку

Hi, Виктор!

Цитата:

Вместо SET PROC у меня несколько Custom классов с UDF
методами

И поскольку они у тебя статичные (созданы в глобальной DS), то их код
работает внутри этой самой DS. А соответственно нарисовать например
процедуру работы с некоторой таблицей заметно сложнее. Также не совсем
понятно что делать если UDF нужен в запросе. Фоксовый движок и так не сильно
любит использование объектов в запросах, а тут ещё и объект живущий в другой
DS потенциально опасная ситуация.

Цитата:

Эм с точкой не нужен если строго следовать Naming Conventions от
Microsoft.

Хорошо, когда ты ЕДИНСТВЕННЫЙ человек, работающий с исходниками программы. И
когда твои технологические наработки (те-же глобальные классы - наборы
UDF-ов) кроме тебя никто не пользует. Иначе как говорится есть моменты Ну
и кроме того, если СТРОГО следовать, то как быть с
llOK и lLok или скажем tnEw и tNew... Всё в рамках соглашения, но
однозначности не наблюдается... У нас из-за этого до сих пор придерживаются
старого стандарта (времён Clipper), где все имена полей начинают с Q. Он
меня по правде говоря бесит, равно как и так нравящиеся кой кому "русские"
сокращения имён полей...
В общем я не вижу никакого вреда от m. тогда как польза явно видима
(повышение надёжности кода).

Цитата:

Я поступил иначе

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

Hi, urfin!

Цитата:

Применение SET ORDER не приводит к изменению свойства
THISFORM.DATAENVIRONMENT.CURSOR1.ORDER

Никогда не пользовался реально этим свойством для проверки текущего
значения - только для установки его в момент открытия курсора. Равно как и
прочими свойствами этого объекта - он для меня не более чем обёртка над USE,
SET ORDER/FILTER ну е ещё парочкой команд. Но никак не механизм отслеживания
состояния соответствующего курсора. Можно вообще совершенно спокойно убить
этот объект (после открытия курсора) и ничего с курсором не станется...
Равно как и наоборот можно поступить.

Цитата:

И еще, хорошо бы поиметь свойство у Exception, равное ссылке на
объект, вызвавший Exception

Мне кажется, что тут всё дело в том, что реально catch работает в другом
контексте (в контексте той процедуры/метода где он находится), и потому и не
может получить информацию из "уже отброшенных из-за ошибки" модулей. Т.е.
похоже что сама цепочка вызовов к тому моменту уже разрушена...
Я пока вплотную не копал try - ибо считаю что это "по задумке" не замена
штатных обработчиков ошибок (Error event объектов), а специальная фишка для
локального отлова ошибок - то что в древние времена делали через
переопределение ON ERROR с последующим восстановлением... А имя процедуры
просто специально сохраняют
Кстати если уж следовать принципу, то до конца - т.е. писать try ВЕЗДЕ - с
соответствующим throw для передачи ошибки на более верхний уровень.

Цитата:

Добрый дедушка Мороз, подари мне на новый год лошадку

... а конык бэз ногы, гы-гы гы-гы гы-гы

Предлагаю немного расслабиться и

http://i72.by.ru/humor/revolution.htm

История программных революций от Microsoft, вкратце:

Сначала были Windows API и DLL Hell. Революцией N1 было DDE - помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток - его писали не они!

Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием <по месту>, при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.

Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда - и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток - его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).

Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции <System File Protection>, исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.

Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно - недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили <COM> или <Active> или <X> или <+> - они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про <Windows DNA> (почему не DINA) и <Windows Washboard>, и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.

К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как <doughnut (пончик по-нашему)>, но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.

В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.

Оригинал:

First, there was the Windows API and DLL Hell. Revolution # 1 was DDE — remember how hot links let us create status bars showing the current price of Microsoft stock? About that time, Microsoft created the VERSIONINFO resource, which eliminated DLL Hell. But another group within Microsoft discovered a fatal flaw in DDE: they didn't write it!

To solve that problem, they created OLE (which was like DDE, only different), and I fondly remember a Microsoft conference speaker proclaiming that the Windows API would soon be rewritten as an OLE API, and every control on the screen would be an OCX. OLE introduced interfaces, which eliminated DLL Hell. Remember "in situ" fever, and how we dreamed of the day that our applications would all be embedded in a (apparently very large) Word document? Somewhere in there, Microsoft got the C++ religion and MFC emerged and solved all our problems again, but with inheritance.

Well, OLE wasn't going to take that sitting down, so it re-emerged as COM, and suddenly we realized what OLE (or was it DDE?) was really meant to be all along — and it even included an elaborate component version system that eliminated DLL Hell. Meanwhile, a renegade group within Microsoft discovered a fatal flaw in MFC: they didn't write it! They forthwith corrected that problem by creating ATL, which is like MFC, only different, and tried to hide all those fascinating details that the COM group was trying so hard to teach us. This stimulated the COM group (or was it OLE?) to rename themselves ActiveX and issue hundreds of pounds of new interfaces (even new versioning interfaces, which eliminated DLL Hell), along with the ability to make all our code downloadable via web browsers, complete with user-selectable viruses (ha — try to keep up with that, you ATL weenies!).

Like a neglected middle child, the operating systems group cried out for attention by telling us all to "get ready for Cairo", some weird crud that they could never really explain, let alone ship. To their credit, however, the operating system group did introduce the concept of "System File Protection", which eliminated DLL Hell. Meanwhile, another group inside Microsoft discovered a fatal flaw in Java: they didn't write it! That was remedied by creating J, or Jole, or ActiveJ (honestly, I can't remember the name), which was like Java, only different. That was very exciting, but Sun sued Microsoft under some archaic law that limits the amount of crapulence any one company can ship in a year. This was clearly an attempt to stifle Microsoft's freedom to create products that are like other products, only different, and resulted in the creation of The Microsoft Freedom to Stuff Money in the Trousers of Congressmen Network (newsletter and $14.75 T-shirts available).

Remember the J/Jole/ActiveJ program manager pounding his shoe on the table and insisting that Microsoft would never abandon his product? Silly wabbit! All this could mean only one thing — too little attention for the ActiveX (or was it COM?) group. This incredibly resilient herd of API gushers came back strong with COM+ (shouldn't that have been ActiveX+?), and MTS. (I have no idea why there's no "COM" or "Active" or "X" or "+" in "MTS" — they totally shocked me with that one!) They also threatened to add yet another "+" onto all their buzzwords in the very near future. Around that time, someone was yelling about "Windows DNA" and the "Windows Washboard" for a while, but that died out before I ever figured out what it was.

At this point, Microsoft had been watching the Internet for several years with growing unease. Recently, they came to the realization that there was a fatal flaw in the Internet: well, you probably know what it was. And that brings us up to date with .NET (pronounced like "doughnut", only different), which is like the Internet, only with more press releases. Let's be very, very clear about one thing: .NET will eliminate DLL Hell. .NET includes a new programming language called C# (turns out there was a fatal flaw in Active++Jspresso, so just as well it died). .NET includes a virtual runtime machine that all languages will use (turns out there's a fatal flaw in relying on Intel CPUs).

.NET includes a single logon system (turns out there's a fatal flaw in not storing all your passwords on Microsoft's servers). In fact, it's probably easier to list all the things that .NET does not include. .NET is absolutely going to revolutionize Windows programming... until next year.