 | | | | |
Полный текст материала
Цитата или краткий комментарий: | «... Первоначальная идея была проста, написать несложную программу, исходный текст которой можно было бы использовать как некий шаблон, с реализованной функциональностью, отвечающей наиболее часто выдвигаемым требованиям. ...
Желательно предусмотреть возможность масштабирования размеров окон, а также размеров и положения всех визуальных элементов, расположенных на ней, после изменения размеров экранного шрифта. Размеры окон и визуальных компонентов не должны меняться при изменении разрешения экрана.
...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 6 | 75% | | | | | Ничего особенно нового и интересного | | [2] | 2 | 25% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 8 | | | | Все понятно, материал читается легко | | [1] | 7 | 100% | | | | | Есть неясности в изложении | | [2] | 0 | 0% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 7 |
[TControl] [Изменение размеров компонент, нестандартная форма] [Координаты компонент, относительное расположение.]
Отслеживать это обсуждение 
Всего сообщений: 1601-09-2005 06:36Здравствуйте!
Меня заинтересовало решение проблемы масштабирования окон. Приведенные решения просты и применимы. Но!
Как бы сделать тоже самое, но с формой, которая имеет изменяемый размер, и все контролы которой привязаны к форме Anchor-ами и меняют свой размер в зависимости от размеров формы. В таком случае при масштабировании у меня происходит следующий процесс: сначала масштабируются контролы, потом масштабируется форма и при этом контролы дополнительно разъезжаются из-за изменения размеров формы.
Что можно сделать в таком случае, кроме запоминания Anchors контролов, их отключения и последующего включения после масштабирования? |
|
25-09-2002 15:53мне пришлось разбить сообщение надвое, а то, вроде, Королева просила не писать длинных постингов.
>Лично я не вижу особой выгоды от самотестируемого кода. 90% того,
> что он делает, достигается простым грамотным написанием программы
> (директивы компилятору, Assert и т.д.). А оставшиеся 10% не стоят
> временных затрат. Imho.
Про 10% - уверяю Вас, гораздо больше, 10% - это то, что Вы подозреваете, на самом деле, и где то есть об этом информация, ошибок больше. Это так называемые некритичные ошибки, или ошибки на определенные комбинации входных параметров.
Вообще, Вы наверно не заметили, но в статье указано на странности поведения Constraints, при масштабировании, странность эту я выловил в свое время с помощью теста, даже не подозревая о ней, при этом не прилагал ни каких лишних усилий. И уж тем более, как нормальный человек, я сначала делаю, если не получается - смотрю в инструкцию. Кстати, я поискал, но не смог найти указания в интернете на такое поведение Constraints. Это не баг, по тому что не описано в хелпе как должно быть, но это и неправильно.
С уважением.
|
|
25-09-2002 15:17Уважаемый Айнвилл.
>Естественно, ибо это не задача программиста. В прличной конторе этим
> занимается отдельная команда -- тестеры. И смею Вас уверить, задача
> создания грамотного и эффективного набора тестов -- это отдельное
> искусство и отдельная наука.
это самое распостраненное заблуждение среди программистов, почитайте классиков - очень уважаемых людей, кстати.
Ни какое это не искуство и ни какая это не наука, если проект грамотно организован, то это просто "дело техники".
Да, действительно, иметь отдельную команду тестеров - хорошо. Но она должна заниматься функциональными тестами, технологические тесты - все на совести кодера.
Достаточно примитивные, традиционные способы вносят изменения в программу, например Assert, или еще какие-то методы, типа ведения лога и т.д. Да, можно поступать и так, я сам так когда то делал. но...
Есть одна важная проблема, которую многие не понимают, и похоже Вы в том числе. Проблема контроля качества. Как Вы сможете доказать, что Вами написанные процедуры работают корректно? Только не надо предлагать методов типа "нажать и посмотреть" - это не серьезно, подходит только для любителей, которые пишут "для себя". Так вот, доказать Вы это не сможете, с Вашими Assert"ами, или что там еще.
Еще раз, большими буквами, после удаления проверочных процедур Вы не сможете убедительно доказать, что все работает так же, как и в их присутствии - Вы меняли код, а значит могли допустить ошибки.
Еще проблема, пришлось вносить изменения, через некоторое время, в процедурку, для того, что бы протестировать правильность изменений, Вы что? будете опять вносить Assert и т.д? Я много раз сталкивался с тем, что после внесенных изменений, в программах кустарей, появляются новые ошибки. Если бы все тестировалось автоматически, и я видел это на нескольких примерах в жизни, то такая проблема решалась бы гораздо легче, и жизнь была бы проще.
Так что, Вы не правы, первоочередная задача программиста - написание БЕЗОШИБОЧНОГО кода, корректность которого МОЖНО ПРОВЕРИТЬ. Кстати, если бы Вы сталкивались с "серьезным" ПО, стоимостью в несколько миллионов $, от весьма уважаемых производителей (не M$, естественно), то знали бы, что все они поставляются, как минимум, с набором процедурных и функциональных тестов. Более того, документация может быть поставлена за отдельные деньги, но тесты бесплатны и обязательны. В результате, и продавец и покупатель УВЕРЕНЫ, что все работает так как надо, и что в новую версию не внесено новых ошибок. И все довольны, мы готовы и дальше оплачивать мейнтананс, они готовы тратить этот мейнтананс на развитие софта, ну и на личные нужды.
Так что, вот так вот делаются дела у взрослых мальчиков :)
С уважением.
ЗЫ,
еще кое что - наш софт(который мы используем) не управляет ядрёными реакторами, ни охраняет воздушное пространство, не считает деньги вкладчиков и даже не является системой реального времени.
|
|
25-09-2002 11:43> Кстати, с чего все началось, опытные программисты, которых я опрашивал (смею уверять они все уважаемые в своем деле люди), действительно имеют самое отдаленное представлени о технологиях и контроле качества.
>
Естественно, ибо это не задача программиста. В прличной конторе этим занимается отдельная команда -- тестеры. И смею Вас уверить, задача создания грамотного и эффективного набора тестов -- это отдельное искусство и отдельная наука. Конечно, хорошо, если с ней знаком программист, но все-таки для него это не первоочередное занятия.
Лично я не вижу особой выгоды от самотестируемого кода. 90% того, что он делает, достигается простым грамотным написанием программы (директивы компилятору, Assert и т.д.). А оставшиеся 10% не стоят временных затрат. Imho. |
|
25-09-2002 11:32Честное слово, устал я Вам объяснять, уважаемый Айнвилл,
одну простую вещь - все это, ключи, формы, и т.д. всего лишь фон, декарация, и т.д. для демонстрации того, что есть простые и довольно эффективные способы тестирования приложений, своих же собственных, и есть технологии программирования, довольно эффективные.
Если Вам будет легче, могу сказать что, я знаю как можно обрабатывать командную строку, как стандартными средствами, либо как это делает сишный GetOpts(). Не в этом дело. Статья то для НАЧИНАЮЩИХ, может быть кто то из них и заинтересуется Технологиями Программирования. И может быть, кто то станет пользоваться системами технологического тестирования - это не сложно, а выгоды, в конечном счете, большие.
Но если Вы действительно, знаток разбора командной строки, Вы можете проявить себя, написать совершенно простенькие процедурки, которые реализуют это самый разбор, в пределах требований, вместе с тестами, прислать мне и я с удовольствием включу это в статью. Естественно с ссылкой на Ваше авторство.
Ну как, согласны?
ЗЫ
Кстати, с чего все началось, опытные программисты, которых я опрашивал (смею уверять они все уважаемые в своем деле люди), действительно имеют самое отдаленное представлени о технологиях и контроле качества. А это, отсутствие контроля качества и технологии, и это уже было доказано хотя бы организацией ISO или появлением CMM, в полном смысле этого слова - кустарщина. Любая успешная профессиональная деятельность, в любой области, опирается на либо на известную технологию, либо на технологию собственного производства.
|
|
24-09-2002 18:38Автору:
> myProg.exe /console /nologo /config="..\..\myProg.cfg"
>
А-а-а... Господи, да в чем же проблема?
Как выше предлагалось, пишем наследник от TStringList, который, к тому же, умеет считывать параметры не только из командной строки, но и из файла. Имя файла, берем в MyStringList.Values["config"]. |
|
24-09-2002 15:45нет, не так. пример:
myProg.exe /console /nologo /config="..\..\myProg.cfg"
в myProg.cfg:
/param1
/param2
...
ну и так далее. не уже ли не знаете? почти все Борланские продукты поддерживают такую возможномть. У WinRAR то же есть, ну и т.д.
И ни какого тут интерпретатора не надо.
С уважением.
|
|
24-09-2002 11:43Автору:
> Вы меня не понили, речь идет не о командной строке, а о возможности передачи программе файла с управляющими ключами, которые бы расценивались как командная строка
>
Э-э-э... Я Вас, действительно, не понял. Вы подразумеваете обработку
строк вида
DefaultImage BITMAP "city2_5.bmp"
в файле, указанном в строке параметров?
Если да, да еще подразумевается обработка строк в общем виде, то, получается, вы хотите вставить в свою программу достаточно общий интерпретатор. Смысла в этом, по-мойму, нет. Ибо
1) В крайне не большом количестве проектов это требуется (а ведь Вы создаете некоторую базу для большинства своих проектов)
2) Такого рода конечных автоматов написано привеликое множество; они есть и в Freeware. |
|
24-09-2002 06:03Уважаемому Айнвилл.
1. о DUnit и технологиях программирования.
2. Вы меня не понили, речь идет не о командной строке, а о возможности передачи программе файла с управляющими ключами, которые бы расценивались как командная строка.
С уважением... |
|
23-09-2002 19:13> Вы приписываете собственные мысле автору, и на основании этих мысле приходите к заключениям, в общем то не совсем верным
>
Хорошо, тогда приведу точную цитату:
"Однако оказалось, что подавляющее количество достаточно опытных программистов, имеют лишь приблизительное понятие об изложенном материале."
Так вот, повторяя вопрос; о каком из тезисных пунктов "подовляющее количество достаточно опытных программистов имеют лишь приблизительное понятие" ???
> Кстати, если Вы знаете, как легко и просто организовать обработку файла с ключами, примерно так, как это делает BCC32.EXE, сообщите, включу в статью
>
Я бы делал это так: написал наследника от TStringList, в котором был бы "парсер" командной строки; этот "парсер" заносил бы в StringList строчки, соответствующие указанным в командной строке ключам, так, чтобы далее к ним можно было бы обращаться через свойство Values у TStrings. По-мойму, это оптимальный подход.
|
|
23-09-2002 10:53
23-09-2002 06:55Уважаемый Айнвилл,
Вы уж меня извините, но Вы приписываете собственные мысле автору, и на основании этих мысле приходите к заключениям, в общем то не совсем верным.
Видите ли, статья для начинающих, задумана как попытка собрать вместе то, что обычно (по моему скромному мнению) довольно часто используется при написании программ. Так же, это попытка обратить внимание людей на такую простую и нужную вещь как DUnit и на то, что кроме обычного, банального, кодинга существуют целые технологии программирования.
В принципе, при обработке ключей больших проблем никогда небыло. Кстати, если Вы знаете, как легко и просто организовать обработку файла с ключами, примерно так, как это делает BCC32.EXE, сообщите, включу в статью.
|
|
21-09-2002 14:44По-мойму я задал кристально понятный вопрос. Вы в статье писали, что столкнулись с трудностями; спрашивали у знакомых как с ними справляться; искали в интернете, и пришли к выводу что трудности эти никем еще не разрешались.
Собственно, вопрос, о каких трудностях речь. Ну, не станете же Вы утверждать, что запуск программы с ключами, обработка этих ключей -- есм сложная проблема? |
|
21-09-2002 12:17Уважаемый Айнвилл.
Если Вы были внимательны, то могли заметить такие слова: "Предложения будут рассмотрены, претензии - проигнорированы." К какой категории Вы сами отнесете свой постинг? к предложениям или претензиям?
Я понимаю предложение Anna, или скорее намек, поскорее заняться тем, что бы "..хотяб положение сверху, сбоку запоминалося."
С уважением. |
|
21-09-2002 00:45 Вопрос автору: а что такого принципиально неизвестного в анонсированном проекте? Да, это довольно нудный по выполнению, трудоемкий процесс, но (возможно я проглядел?) ничего сверхсложного/неизвестного в нем нет.
Я не прав? |
|
20-09-2002 21:07| Номано, давно искала как свои проекты начинать чтоб хотяб положение сверху, сбоку запоминалося. |
|
|
|
