@Jin X

Добавляем в пустое PopupMenu несколько пунктов динамически (шириной, например, до 50 символов).
Отображаем его – всё нормально. Затем удаляем все пункты (Items.Clear) и добавляем новые, но более короткие (до 10 символов). Снова отображаем. Ширина окна PopupMenu такая же, как и при прошлом вызове, т.е. гораздо шире расположенного в нём текста. WTF?
Это ещё один баг или как?
p.s. Не знаю что будет, если сделать наоборот: сначала короткий текст, а потом длинный. Не пробовал... И только в Tokyo, в 7 и др. не пробовал.

0

@northener

Jin X, Давайте скажем так.
Ширина PopupMenu до сих пор никого не волновала. Да и не должна бы волновать никого. В меню, по определению, должны быть однословные названия. Нафига в меню нужно использовать что-то ещё типа многословного текста?
Не. Ну если вам/вас приспичило, то пожалуйста пишите свои компоненты.

0

@krapotkin

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

0

@Jin X

Не приходилось создавать popup-меню на чистом WinAPI, но вероятно, что где-то в свойствах класса TPopupMenu (приватных, например) хранится ширина, которая указывается при создании окна меню.

Добавлено через 2 минуты
С чего вы решили, что ДОЛЖНО быть так, как вам кажется? По какому определению так должно быть? И с чего вы взяли, что это НИКОГО не волновало? Потому что не волновало вас лично???
Что за стереотипы?

А если я напишу 3 слово общей длиной в 30 символов – это укладывается в ваши понятия нормального размера? А 20 символов?
А потом создам 3 пункта из 3 символов. И ширина такого меню будет равна ширине 30-символьных пунктов. Это нормально?

Добавлено через 3 минуты
В моём понимании программная реализация чего-либо должна работать нормально для любых входящих данных.
Задали 100 символов – будь добр отобразить все 100 и отобразить нормально. И зачем мне понадобилось 100 – того, кто этот компонент делает, волновать не должно. Задали 1000 – значит в конце должно быть многоточие, например (если все символы не умещаются в ширину экрана). Но это не должно выглядеть криво.
Именно из-за того (отчасти), что кто-то думает, что чего-то быть не должно по определению и возникают проблемы типа переполнения стека и прочие уязвимости, которыми пользуются авторы эксплойтов и т.п.

0

@krapotkin

никто не отменяет принципа разумной достаточности
есть ограничение на длину пути в имени файла, на длину самого имени, не обязаны программы работать на любых мыслимых разрешениях и шрифтах
уязвимости должны быть ограничены, элементы меню обрезаться, но если не обрезаются, вы можете написать в QC Microsoft и подождать, когда разработка дойдет до вашего тикета
но возникает разумный вопрос
вам шашечки или ехать?
как пересоздать меню с нуля вроде все понятно
Menu.Free
menu:=TMenu.Create(Self)
ну накрайняк еще пара каких-нибудь строк для WinApi. Это ж меню, огого.
вот собсно из-за этих строк столько пара?

0

@Jin X

Создать новое меню не проблема, конечно.
Но речь-то не об этом. А о том, что при очистке и добавлении вот такая странная вещь происходит. Хочется разобраться что к чему.

0

@krapotkin

где-то в дебрях VCL
я лично концов не нашел
упоминания о ширине есть только в прорисовке тем а там черт ногу сломит
но пересоздание работает прекрасно. я проверил

1

@northener

Ув. krapotkin, уже сказал почему.
И если вы подумаете, то и сами поймёте этот принцип.
Ещё раз постарайтесь подумать и может быть поймёте что это невозможно для любых входящих данных.
Вот вы предложили, что нужно заменить последние символы многоточием. Но если речь идёт об имени файла в пункте меню, то что вам даст это многоточие?

0

@Jin X

Длину конкретно на имя файла должен ограничивать не контрол/класс/etc, а программист, который это имя файла туда посылает (потому как контрол не знает, да и не должен знать, какого вида строка ему передаётся), а если он этого сделать не потрудился, то ничего не остаётся как просто обрезать или заменить концовку многоточием.

А какой вариант вам кажется более логичным? Что должно произойти? Надо обрезать на 30 символах или пусть выходит за пределы экрана, т.к. "это невозможно для любых входящих данных"?
Я скажу так: возможно, но не всегда (но чаще всего вполне возможно). По крайней мере, стремиться к этому нужно.
Под любыми входящими данными я подразумеваю не типы строк, разумеется (т.к. в данном случае – для PopupMenu – это ни к чему), а например, проверка на пустую и слишком длинную строку. Разве это слишком много условий, которые нужно проверить?

Кстати, вы сами ответили на свой вопрос: "Нафига в меню нужно использовать что-то ещё типа многословного текста?" Например, при указании списка файлов. Откройте меню "Recent Files" в любом редакторе и увидите, что там не только "однословные названия". Да, это не PopupMenu, но это не сильно меняет сути, т.к. PopupMenu со списком файлов вполне может открываться, например, при нажатии на кнопку или по right-click, и в одном из подменю может быть список Recent Files.

0

DenNik

вот есть редактор, который сохраняет пути всех последних открытых файлов в виде меню с полным путем к файлу в качестве заголовка пункта меню. а пользователь открыл файл из 100 вложенных папок + имя файла на over 50 символов. и в чем здесь вина программиста?

0

@Jin X

Да я ж не о том. Я про то, что если имя слишком длинное, то чтобы оно не было обрезано автоматом из-за того, что не помещается на экране, лучше это сделать самому (обрезать текст чисто для PopupMenu).

Добавлено через 2 минуты
ИМХО, лучше пусть будет D:\All of my Projects\Video\Adobe Premiere\...\Новый год\2018 - Мы в Подурюпинске\VIDEO1022.MPG, чем D:\All of my Projects\Video\Adobe Premiere\Семейные архивы\Мама, папа, я\Новый год\2018 - Мы в Подурю

0

@krapotkin

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

0

@Jin X

Да почему дебил-то?
У каждого своя задача.
У проектировщика интерфейса – сделать так, чтобы приемлемо выглядела любая строка.
У программиста конечного приложения – чтобы конкретно его формат данных (имя файла, к примеру) выглядел хорошо (если не устраивает вариант по умолчанию).

Разве там написано, что пункты в PopupMenu должны быть не длиннее 20... 30... 40... 78... символов? Если привязываться конкретно к данной истории...

0

@krapotkin

потому что программист всего лишь кодирует то, что выдал ему архитектор и дизайнер
и если в постановке дичь, то ..
там написано ДЛЯ ЧЕГО используются элементы интерфейса
https://msdn.microsoft.com/en-... s.85).aspx

а еще есть общие принципы UX
которые просто кричат о том, что нечего делать в меню строкам размером с черное море

0

@Jin X

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

Тем не менее, те же "Recent Files" нередко нарушают это правило. Причёт, довольно серьёзные приложениях типа Adobe Photoshop вполне записывают туда строки, создающие ширину окна до 500+ пикселей. Visual Studio использует многоточия для сокращения пути. А вот Notepad ++ (вероятно, не лучший пример для подражания) с шириной вообще особо не заморачивается.

0

@northener

Вообще-то говоря идея MRU (Most Recently Used) не предполагает упоминания имен файлов. Она более заточена на использование имён документов.

0

@krapotkin

точнее, путей. Имена там достаточно часто

0

@yashcher

Может я чуть чуть опоздал) Но попробуйте выставить в свойствах PopupMenu Owner = true.

По крайней мере мне помогло.

0

@Rayvenor

И в нём работает именно так как вам не нравится - если пункт меню длинный, то после изменения длины содержимого он остаётся длинным. Провёл эксперимент: Screenshot_1.jpg - есть длинный путь к файлу, Screenshot_2.jpg открыл, закрыл файл с коротким путём, длинный путь пропал из меню, но меню всё ещё длинное. Screenshot_3.jpg перезапустил Notepad ++, меню пересоздалось и соответствует ширине содержимого. Так что действительно это системное и никого не волнует.

Миниатюры

     

0