PDA

View Full Version : Tooltip bugs



Nils G. Svedmyr
15-May-2009, 07:50 AM
VDF 15 Beta 2 Windows XP sp3

BUGS:
a) "Move Self to ghoToolTipController" is not added to the cToolTipController object when a cToolTipController is dragged from the Class Palette on to an existing program (name list or program frame).

b) When dragging a cToolTipController from the Class Palette on to the name list on to an existing program, the object is created in the oMain object - not at the desktop level below the cApplication (This is what John T. webinar shows)

c) When setting the piIcon property to:
Set piIcon to TTI_INFO_LARGE
the error icon will get displayed instead of a large info icon.

SUGGESTION:
d) The CodeJock controls allow one to set the tooltip style to any of the following:
Balloon, Luna, Office, Office 2007, Selected Visual Theme Style or Standard.

Although I love the new ToolTip feature, VDF applications would look much more coherent if it was possible to set the ToolTip style the same way it can be done with the CodeJock controls.

Just a thought...:)

Best regards,
Nils G. Svedmyr

John van Houten
15-May-2009, 08:48 AM
VDF 15 Beta 2 Windows XP sp3

BUGS:
a) "Move Self to ghoToolTipController" is not added to the cToolTipController object when a cToolTipController is dragged from the Class Palette on to an existing program (name list or program frame).

b) When dragging a cToolTipController from the Class Palette on to the name list on to an existing program, the object is created in the oMain object - not at the desktop level below the cApplication (This is what John T. webinar shows)

c) When setting the piIcon property to:
Set piIcon to TTI_INFO_LARGE
the error icon will get displayed instead of a large info icon.

Nils G. Svedmyr

Hi Nils,

a) The reasoning is that it is possible to have multiple cToolTipController objects in an application. You'd do this to have different tooltip styles for different sets of tooltip strings. In this case you would not want to set ghoToolTipController in every object.

When you create a new application it comes with a built-in cToolTipController object with ghoToolTipController set. This is what you want.

The problem with this is when you have an existing application and you want to add a cToolTipController object. In this case you 'do' want to set ghoToolTipController.

If we change the .dfo for this class so that it sets ghoToolTipController then someone who creates multiple cToolTipController objects might report a bug that ghoToolTipController is set in each one by default.

So in summary there are two occasions where you would want to drop a cToolTipController object from the Class Palette: 1) Where you have a pre-existing application without a cToolTipController; 2) You have a application with a cToolTipController and you want to create a second (or third etc) cToolTipController object.

One solution (were ghoToolTipController is not set in the .dfo) favors applications with an existing cToolTipConroller. As time passes this becomes more and more the better solution.

The other solution (where ghoToolTipController is set in the .dfo) favors applications built prior to VDF 15.0 but is a disadvantage if your application already has a cToolTipController object. As time passes this becomes a worse and worse solution.

b) Yes, I am also not very happy about the positioning of the object in code after drag and drop from the Class Palette. Currently the Visual Designer positions any new object below all new existing objects at the same level. This means that if you drop a cToolTipController onto the vacant area around the main panel then it will be created as a sibling of the main panel object (good) but will be positioned below it (bad). This means you have to know to move the object up above the main panel. We are aware of this issue, but like I said, I'm not too happy about it. This is a bit tricky to solve though.

c) Set piIcon to TTI_INFO_LARGE: In VDF, the large icon constants are only supported on Windows Vista and above. We have adjusted the documentation to show this.

regards John van Houten

Dennis Piccioni
15-May-2009, 09:30 AM
In VDF, the large icon constants are only supported on Windows Vista and above. We have adjusted the documentation to show this.

Actually, not yet -- this doc change won't be in the next public build, but the following one.

Nils G. Svedmyr
15-May-2009, 01:28 PM
Hi John,

Thanks for your reply.


Hi Nils,

a) The reasoning is that it is possible to have multiple cToolTipController objects in an application. You'd do this to have different tooltip styles for different sets of tooltip strings. In this case you would not want to set ghoToolTipController in every object.

When you create a new application it comes with a built-in cToolTipController object with ghoToolTipController set. This is what you want.

The problem with this is when you have an existing application and you want to add a cToolTipController object. In this case you 'do' want to set ghoToolTipController.

If we change the .dfo for this class so that it sets ghoToolTipController then someone who creates multiple cToolTipController objects might report a bug that ghoToolTipController is set in each one by default.

So in summary there are two occasions where you would want to drop a cToolTipController object from the Class Palette: 1) Where you have a pre-existing application without a cToolTipController; 2) You have a application with a cToolTipController and you want to create a second (or third etc) cToolTipController object.

One solution (were ghoToolTipController is not set in the .dfo) favors applications with an existing cToolTipConroller. As time passes this becomes more and more the better solution.

The other solution (where ghoToolTipController is set in the .dfo) favors applications built prior to VDF 15.0 but is a disadvantage if your application already has a cToolTipController object. As time passes this becomes a worse and worse solution.


a) Ok, point taken and I agree that it is a temporary problem only. I should have checked the help that clearly explains how it works. I guess it is one of those things you just have to learn and handle once, and after that it will be no problem.

An idea though would be to insert a ""//Move Self to ghoToolTipController" into the .dso text - which will make it much clearer for first time users. I was getting somewhat annoyed when nothing happened at all after adding the Tooltip object. Well, its just an idea.



b) Yes, I am also not very happy about the positioning of the object in code after drag and drop from the Class Palette. Currently the Visual Designer positions any new object below all new existing objects at the same level. This means that if you drop a cToolTipController onto the vacant area around the main panel then it will be created as a sibling of the main panel object (good) but will be positioned below it (bad). This means you have to know to move the object up above the main panel. We are aware of this issue, but like I said, I'm not too happy about it. This is a bit tricky to solve though.


b) Ok, I understand. I guess everything seemed clear like mudd how to get the ToolTips to work for me - especially when combined with a) above. I hope you come up with some good idea how to improve it though ;)



c) Set piIcon to TTI_INFO_LARGE: In VDF, the large icon constants are only supported on Windows Vista and above. We have adjusted the documentation to show this.

regards John van Houten

c) Ok, I also read Dennis message that it will make it into the help. BUT, would it be possible to somehow display TTI_INFO (small icon) instead of the TTI_ERROR icon?

Cheers,
Nils G.

John van Houten
18-May-2009, 09:16 AM
c) Ok, I also read Dennis message that it will make it into the help. BUT, would it be possible to somehow display TTI_INFO (small icon) instead of the TTI_ERROR icon?

To be honest I don't know why it is displaying the TTI_ERROR icon. I guess the thing to remember is don't use the large icons unless you are deploying on Vista or above.

- John v

- John

Nils G. Svedmyr
18-May-2009, 08:55 PM
OK, fine enough for me.

- Nils G.