есть некий суперкласс, который сам наследует QGraphicsItem, и от которого наследуют несколько классов, реализующих изображаемые на сцене объекты, в инстансе суперкласса, в поле QString содержатся наименования этих объектов, и там все пучком работает

но появилась необходимость добавить комментарии, есть смысл наследовать тот же суперкласс, поскольку в остальном комментарии по поведению очень похожи на реализованные объекты, а в суперклассе уже есть поле класса QString, то есть соблазн в него же уложить комментарии

но! комментарии должны быть многострочные, поэтому прежде чем браться за их реализацию таким способом, хочу выяснить для себя несколько вопросов, поскольку с таким использованием QString пока не сталкивался

- как в QString хранятся esc-символы, особенно перевод строки? достаточно ли просто уложить туда строку с '\n' и оно там будет нормально лежать? а что насчет `\t`?
- как подсчитать размер boundingRect для такой строки? есть ли уже готовое средство для такого подсчета, учитывающее `\t` и `\n`, или надо самому лазить по строке и считать количество видимых строк, табуляции etc?
- как будет выполняться отрисовка такой строки при вызове ((QPainter*)painter)->drawText(...); с установленными метриками и заданным прямоугольником? будет ли `\n` распознаваться как полный перевод строки с возвратом каретки? или как пробел? или только как перевод строки, без возврата каретки? будет ли распознаваться `\t`? на какой шаг табуляции?

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

тем, что в них приходится над штатными средствами Qt морочить еще надстройку, и не забывать ее использовать


библиотека написана на С, там просто устанавливается код ошибки, и даже не всегда возвращается false, то есть, надо после вызова функции проверять глобальную переменную на 0, надстройка над этой библиотекой написана на С++, и с Qt никак не связана, дополнительные функции просто также устанавливают код ошибки в этой же переменной - поэтому самое последнее предложение высылать сигнал не проходит в принципе

слоты - это простые короткие переходники, которые получают сигналы и вызывают функции библиотеки или надстройки над ней

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


где глобальная функция GloballErrorMessage() проверяет наличие кода ошибки, если он есть, выдает сообщение, и сбрасывает код в 0 - и использовать в конце каждого слота этот макрос вместо return - единственный минус тут - не забыть, что надо писать не return - хотя это конечно тоже хак...

но тут другой момент... вроде бы получается перевести все слоты в один объект, наследующий QMainWindow, а там вроде есть подходящий обработчик

откуда посылать? из слота? из функции, делающей emit? слотов несколько десятков, мест для emit еще больше, и на множество слотов сигналы идут из меню приложения, от разных кнопок и прочих виджетов, созданных в QtDesigner

че-то не нравится ни один предложенный вариант 

лучше всего, если бы можно было переопределить приложение, а там виртуальный метод что-нибудь вроде AfterSignalProcessed(), который вызывается каждый раз, когда завершился любой обработчик любого сигнала

такого нет?

вопрос в заголовке возможно не очень прозрачен, поэтому пояснение:

есть приложение с меню и кнопками на тулбарах, пункты меню посылают сигналы туда, куда подключены

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

после обработки сигналов необходимо выдавать сообщение об ошибке, при этом более чем в половине случаев невозможно выдать это сообщение, поскольку код устанавливается библиотечными функциями

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

каким образом можно получить управление после того, как любой сигнал был обработан его приемником, независимо от того, откуда он был послан? все описанные сигналы и приемники находятся в одной нити приложения, но сигналы посылаются разными объектами

-1

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

извиняюсь за оффтопик, не я начал...

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

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

или что еще хуже, невосстановимые

неа, нигде ведь не сказано, что надо... и раньше был курсор

вызвал... появился...

спс...

есть класс, наследующий QLineEdit, почти полностью, конструктор пустой, только переписаны keyPressEvent(), focusInEvent() и focusOutEvent()

все прекрасно работало, как-то не обращал внимания, изначально курсор был при попадании фокуса в редактор строки

и вдруг пропал... 

получается, он вроде как "автоматический", и если специально о нем не позаботиться, то не предсказуем? однако даже забота не привела к его появлению - вызываю setCursor(Qt::IBeamCursor); откуда либо, хоть из конструктора, хоть из focusInEvent() - по барабану, курсор не появляется...

или я описание QWidget с утра плохо читаю и не вижу решения, или тут какая-то собака порылась... кто-нибудь подскажет, куда смотреть?

не, барахло получается...

написал запрос на багтрекере, поддержите плз

ха! так оно еще и не так банально по-умолчанию работает

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


ну и как узнать, у кого убирать подсветку? тупо у "родителя" - не годится

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

потому как при выходе из перекрывающего в перекрытый, последний должен засветиться, а перекрывающий погаснуть

так что не "1 переменная и 2 проверки"

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

в общем, глупая колбаса пока получается, с какой стороны ни подойти 

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

задача ведь достаточно часто встречающаяся...

сейчас при наезде на перекрывающий, вызывается только его метод hoverEnterEvent(), при этом мы остаемся "над" перекрытым, из его пространства мы не выходим (наверняка, если итемы частично перекрыты, то возможна ситуация, когда останемся над перекрывающим, но выйдем из перекрытого)

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

утром в понедельник не могу сразу сообразить, как сделать, чтобы если айтем полностью или частично перекрыт другим айтемом (например, перекрывающий меньше перекрываемого), то при пересечении границы перекрывающего, чтобы у перекрываемого сначала вызывался hoverLeaveEvent(), а потом вызывался hoverEnterEvent() перекрывающего

вроде по описанию похож флаг ItemClipsToShape, но он работает совершенно иначе

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

наверно есть другой флаг какой-то, но с недосыпа не вижу  

...

ага, фик, влоб в реализованной схеме наследования просто сделать


нельзя, ругается, что этот метод protected, придется ломать все

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

должен же быть флаг для таких случаев...

это репаинт на каждый чих надо вызывать... не кошерно...