Страница 13 из 21
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 22 Апрель 2010, 7:26
nik190994
НАЧАЛИСЬ ПРОБЛЕМЫ В 7075...
Файл корректировки бровса исчезает или заменяется на другой ...
Это при генерации в этой версии..
Приходится генерить в 7014 а корректировать в 7075...
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 23 Апрель 2010, 12:26
Дед Пахом
ORS, до какой буквы дошли с ключевыми словами для CC? Мне попалось на букву D: "DROP", это атрибут листбоксов в window-структуре.
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 23 Апрель 2010, 12:45
ORS
Дед Пахом писал(а):ORS, до какой буквы дошли с ключевыми словами для CC? Мне попалось на букву D: "DROP", это атрибут листбоксов в window-структуре.
Уже перевалили за середину, но атрибуты пока не добавляем, т.к. они и так мешаются в обычном СС. Хочется их появление сделать более интелектуальным, т.е. чтобы были видны только нужные атрибуты и в нужном месте. Но для этого нужен детальный контекст, которого пока нет.
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 23 Апрель 2010, 16:51
Дед Пахом
Есть такие константы как FILE:KeepDir, FILE:LongName и т.д. Они есть в списке CC, но когда наберёшь FILE и жмёшь двоеточие, то окно CC благополучно закрывается.
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 25 Апрель 2010, 15:13
ORS
Дед Пахом писал(а):Есть такие константы как FILE:KeepDir, FILE:LongName и т.д. Они есть в списке CC, но когда наберёшь FILE и жмёшь двоеточие, то окно CC благополучно закрывается.
Есть queue с префиксом FILE:, поэтому когда вы набираете FILE и жмете ':', то СС думает что вы набираете префикс и закрывается, чтобы открылось СС окно для этой queue, но у нее стоит атрибут TYPE, поэтому, собственно, потом окно для нее не открывается. Можно нажать Ctrl+Space чтобы снова увидеть список констант.
В принципе такое поведение правильное, нажатие двоеточия после префикса равноценно нажатию точки после имени, в том смысле, что локализует контекст СС до текущего объекта (или объектов в случае префикса). Я вижу только одно решение проблемы, в случае префикса добавлять в СС окно не только информацию из объекта (объектов), но и все эквейты, которые начинаются с набранного текста. Но чем-то оно мне не нравится...
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 25 Апрель 2010, 16:01
ORS
BOB писал(а):Я сделал бы так.
1 Отступы ниже CODE оставил как есть .
2 Отступы выше CODE (или в структурах) определял в настройке и считал бы их не от конца родителя , а
от начала строки . При этом будут выглядеть нормально даже
повторяющиеся структуры (например несколько Queue ) ...
Так вроде preferred column опция как раз для этого и предназначена, разве что она влияет на позицию ключевого слова родителя (от которого у детей будет еще один отступ). Почему нельзя поставить нужное значение в этой опции, а надо делать еще одну, с практически тем же смыслом?
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 26 Апрель 2010, 6:02
BOB
Согласен, но мы же говорим о фантазиях , а там я бы предпочел иметь отдельные отступы например для class и procedure и отдельные для структур и отдельные для текста программы и позиционироваться они должны от начала строки либо как настроишь.Думаю многие присоединятся , но это только мой сон.
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 26 Апрель 2010, 19:39
ORS
BOB писал(а):Согласен, но мы же говорим о фантазиях , а там я бы предпочел иметь отдельные отступы например для class и procedure и отдельные для структур и отдельные для текста программы и позиционироваться они должны от начала строки либо как настроишь.Думаю многие присоединятся , но это только мой сон.
Не всегда большое количество опций это благо. Даже те опции, что есть сейчас большинство и не пытается настроить, а просто выключают Smart режим, т.к. поведение по умолчанию им кажется странным.
И все же мне не понятно, почему не устраивает одна имеющаяся опция, а хочется много на каждую конструкцию? Любая структура может быть глобальной или локальной, при этом для глобальных структур ключевое слово ставится на preferred column (для всех одинаково), а для локальных сдвигается относительно ключевого слова родителя. Сдвиг этот нужен в частности чтобы END локальной конструкции был сдвинут относительно END родительской.
Какие дополнительные преимущества вам даст эта куча опций по сравнению с тем, что есть сейчас?
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 27 Апрель 2010, 4:23
BOB
Наверно особенности характера. Форматирование локальных структур меня устраивет на 99% , но например в блоке case я бы поздвигал все офы на один отступ , ну легче читается . Причем сдвиг не должен быть большим тк иначе при большом количестве вложений можно уехать за экран . Ну нет так и нет можно привыкнуть , но глобальные структуры однозначно сейчас плохо выглядят .
Причем если лесенки там не бавает , то и отступ можно делать большой т.е. чтобы на соседней строке длинное имя переменной не наезжало бы на описание переменной текущей строки . Для любителей давать длинные и короткие имена переменным нужно увеличить отступ , а это плохо для локальных структур . И еще, если типы переменных выровнять в столбик , то читаемость глобальной структуры значительно улучшается . При чем я не предлагаю искать самое длинное имя в структуре или на всей clw , достаточно дать возможность пользователю самому определить отступ на самое любимое длинное имя и отступы для типов переменных считать от начала строки . Вообще то я думаю Вам работы минут на пять а результат стоит того .
narydprot CLASS(System.Windows.Forms.Form),TYPE,NETCLASS,PARTIAL,PUBLIC
construct procedure(),public
podg procedure()
init procedure()
sqladapter &system.data.sqlclient.sqldataadapter
dbtable &system.data.datatable
itemss &system.data.datarowview
itemsd &system.data.datarow
itemsdk &system.data.datarow[]
krow clarion.windows.forms.entrylistcolumn
pos byte
Код: Выделить всё
narydprot CLASS(System.Windows.Forms.Form),TYPE,NETCLASS,PARTIAL,PUBLIC
construct procedure(),public
podg procedure()
init procedure()
sqladapter &system.data.sqlclient.sqldataadapter
dbtable &system.data.datatable
itemss &system.data.datarowview
itemsd &system.data.datarow
itemsdk &system.data.datarow[]
krow clarion.windows.forms.entrylistcolumn
pos byte
Ну вот такая разница .Кстати текст я вставлял одинаковый (плохо выровненый), но программер этого сайта отформатировал его сам , и почему-то так как мне надо , блин респект ему.
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 27 Апрель 2010, 13:12
ORS
BOB писал(а):Наверно особенности характера. Форматирование локальных структур меня устраивет на 99% , но например в блоке case я бы поздвигал все офы на один отступ , ну легче читается . Причем сдвиг не должен быть большим тк иначе при большом количестве вложений можно уехать за экран . Ну нет так и нет можно привыкнуть , но глобальные структуры однозначно сейчас плохо выглядят .
Сдвиг of от case уже есть, если посмотреть настройки в xml`ьном файле, как я писал недавно. Размер отступа вы определяете сами, настраивая tab size в опциях IDE.
BOB писал(а):Ну вот такая разница .Кстати текст я вставлял одинаковый (плохо выровненый), но программер этого сайта отформатировал его сам , и почему-то так как мне надо , блин респект ему.
Вот я вставил ваш текст в IDE и он отформатировался (размер tab size 2). Честно говоря не вижу большой разницы по сравнению с примером форматирования сайтом выше.
Может вы можете привести какие-нибудь наглядные примеры (картинки) как вам отформатировало IDE, а как бы хотели вы? Потому что я пока никак не могу понять, что текущие опции не позволяют сделать?
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 27 Апрель 2010, 15:05
BOB
Сюда я не могу вставить картинку , а если так:
a[пробел]queue[enter]
b[пробел]clalong[enter]
cccccccccccc[пробел]clalong[enter]
Если у Вас получится оба clalong на одной позиции , то я чего-то не догоняю .
Выделение блока и ctrl + I картины не меняет .Второй clalong сдвинут вправо относительно первого clalong на len(cccccccc) - len(b) потому как все отступы считаются от КОНЦА имени переменной.
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 27 Апрель 2010, 15:21
ORS
BOB писал(а):Сюда я не могу вставить картинку , а если так:
a[пробел]queue[enter]
b[пробел]clalong[enter]
cccccccccccc[пробел]clalong[enter]
Если у Вас получится оба clalong на одной позиции , то я чего-то не догоняю .
Выделение блока и ctrl + I картины не меняет.
Какое у вас значение стоит в опции preferred column (ну и tab size заодно)? При дефолтном 21 (как у меня) оба clalong вполне ставятся на одну колонку, значит у вас значение стоит меньше, причем судя по данному примеру, гораздо меньше. Зачем?
BOB писал(а):Второй clalong сдвинут вправо относительно первого clalong на len(cccccccc) - len(b) потому как все отступы считаются от КОНЦА имени переменной.
Совсем не так, я уже описывал пару постов назад механизм расчета колонки.
"Да, сейчас так и есть, выравнивание идет на один отступ от ключевого слова родителя (от ITEMIZE в примере выше). Если при этом название не влезает, то отступ увеличивается на 2*tabSize пока не влезет. Ключевое слово родителя, в свою очередь, либо имеет 1 отступ от своего родителя, либо, если такового нет, то ставится на preferred column. Соответственно, увеличение значения preferred column, увеличивает шанс, что большинство названий влезет в отведенное место."
Другими словами, слово queue ставится на preferred column, clalong у b ставится на один tab size правее слова queue выше строчкой. Clalong у cccccccccccc тоже пытается поставиться на эту колонку и в случае неудачи (т.е. label не влезает) сдвигается вправо еще на 2 * tab size (и будет так сдвигаться на эту величину, пока не влезет метка).
Опция, которую предложил Дед Пахом, как раз и пригодится для такого случая, когда одна из меток окажется такой длинной, что разумное значение preferred column не поможет и чтобы ключевые слова не стояли вразнобой, они будут выровнены по самой длинной метке.
Added: Только сейчас обратил внимание, что нечто очень похожее реализовано и в форматтере кода на форуме, если посмотреть на предыдущей странице как слова EQUATE сдвинуты в посте Деда Пахома.
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 27 Апрель 2010, 16:08
BOB
Нашел причину . Моноширный шрифт работает правильно , а у меня times new roman.
Как-то жалко от любимого шрифта отказываться и потом если ручками-то довыравнивать ,то все получается и на романе . Встал на начало clalong и как правило достаточно одного таба , но на каждый clalong .Может для таких шрифтов автоматом добавлять пару табов .
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 27 Апрель 2010, 16:55
ORS
BOB писал(а):Нашел причину . Моноширный шрифт работает правильно , а у меня times new roman.
Как-то жалко от любимого шрифта отказываться и потом если ручками-то довыравнивать ,то все получается и на романе . Встал на начало clalong и как правило достаточно одного таба , но на каждый clalong .Может для таких шрифтов автоматом добавлять пару табов .
Ага, теперь наконец-то понятно в чем дело и почему, видимо, столько народу считает нас дураками, которые сделали какую-то фигню и не понимают, чего народ не радуется.
Мы не можем вставлять дополнительных пробелов, т.к. во-первых, то, что вы видите глазами, что можно сюда добавить пару пробелов, или сюда один и все будет ровно, не так то легко посчитать. Во-вторых при смене шрифта или если кто-то другой будет смотреть ваши файлы, то все снова поедет. Если использовать табы вместо пробелов для отступа между меткой и ключевым словом, то на не моноширных шрифтах все вроде тоже смотрится нормально, т.к. размер таба (по-видимому, лень пока смотреть) считается с использованием средней ширины символа. Единственный выход, который я тут вижу это использовать и для пробела среднюю ширину символа, но я не знаю, насколько это легко можно будет сделать и как это скажется на всем остальном виде текста в редакторе.
Re: О сколько нам открытий чудных ... (про C7.1)
Добавлено: 27 Апрель 2010, 17:17
BOB
Во-вторых при смене шрифта или если кто-то другой будет смотреть ваши файлы, то все снова поедет
Это проблема пользователя , пусть заново форматирует.Подсчет ширины конечно проблема, но как-то он же считается сейчас когда я табом ровняю и считается правильно .Я бы не менял существующий расчет ,а добавил бы отдельную процедурку типа вставки пробелов до конца таба плюс один таб, что-то мне подсказывает что существует простое решение.