I have long had to work around issues when using HTML tooltips due to how the tooltip context destroys and deletes the actual tooltip. The issue is with HTML tooltips which must pump messages while waiting on navigation. The problem is while navigation is occurring, the "safe" delete code can be called.

Our HTML tooltips are more dynamic and can take a bit longer for navigation to complete and I have had to resort to all sorts of gymnastics to avoid touching deleted memory when returning from the message pumping loop. 

 Yes, Codejock's own CHTMLToolTip has exactly the same vulnerability — and it has NO protection at all.

  The scenario:

  1. FilterToolTipMessageHelper or SetStyle/ShowImage/ModifyToolTipStyle calls SAFE_DELETEWINDOW(m_pToolTip) — which is
  just ptr->DestroyWindow(); delete ptr; ptr = NULL;
  2. CHTMLToolTip::GetToolSize (line 1785) has a PumpMessage loop at lines 1847-1855 waiting for the IE WebBrowser to
  reach READYSTATE_COMPLETE. While pumping, a dispatched WM_MOUSEMOVE can flow through PreTranslateMessage →
  FilterToolTipMessage → FilterToolTipMessageHelper, which can call SAFE_DELETEWINDOW(m_pToolTip) at line 2437.
  3. When that happens: DestroyWindow() runs (the real CWnd::DestroyWindow — no override), delete runs the destructor
  (~CHTMLToolTip releases m_pBrowserApp, then ~CXTPToolTipContextToolTip and ~CWnd run), and then memory is freed.
  Control returns to the PumpMessage loop inside GetToolSize, which is now executing on a freed this pointer.
  4. The next line — m_pBrowserApp->get_ReadyState(&rs) at line 1854 — dereferences a freed IWebBrowser2* pointer
  through a freed this.

  Codejock has zero protection against this. No deferred DestroyWindow, no deferred delete, no m_bPumping flag, no
  refcounting. The CHTMLToolTip class is shipped with a latent use-after-free.

  The reason it rarely crashes in practice: Codejock's CHTMLToolTip is rarely used (most apps use xtpToolTipStandard or
  xtpToolTipOffice), and when it is used, the IE READYSTATE_COMPLETE pump is usually very fast since the content is a
  simple about: URL with inline HTML. The window of vulnerability is tiny — but it's there.

  Your JHTMLToolTip greatly expanded the pump duration (navigating to file-based HTML, waiting for complex rendering,
  doing multi-pass sizing), which is why you needed the three-layer defense. You weren't fixing a problem you introduced
  — you were protecting against a bug Codejock shipped.

This begs the question - why isn't the CJ source using addref/release mechanism as all the tips are CWnd derived objects? I have code to call InternalAddRef and InternalRelease before and after the pumping code needed to use HTML tips but this "safe" delete, which isn't so safe for me makes no use of ref counting.

My workaround is complex and involves overriding new/delete operators, deferring the actual delete to later. Testing constantly to see if CJ called delete ... all sorts of stuff. But it still suffers from the fact the c++ destructor is called when CJ calls "delete ptr;" My hacks solved most of the crashes when I first used HTML tips but it isn't foolproof due to the destructor running.

I'd like to confirm that all translations for all languages have been reviewed and corrected in the upcoming version. Once the update is available, please review it all again and report any new issues that you might notice.

Thank you.

Regards,

   Alexander

Hello,

I'm wondering how I can change the Caption of the Customize dialog? (e.g. "General Options")

Since I'm using only once custom page is possible to Hide the Tab General, just show the content.

How I can set the width and height of the dialog window? when creates the dialog is too small for the content and user has always to enlarge the window.

Many thanks in advanced.

Cheers

I'd rather Codejock support the latest VS versions faster than delay a release to add massive new features.

Hello,

I can't to run your project

Hello,

I've checked our VB sample and key assign problem not found. May be I need to do additional some actions? 

I've checked with VB6 ActionsSample.

Regards,

Artem Gontarenko

Hi, I have a VB6 MDIForm with a CommandBars control, and have aligned a PictureBox on the left. In the CommandBars_RepositionAlignedControls event handle, I call CommandBars.MoveAlignedControl on the PictureBox, and everything looks good.

However, I want to change the width of the PictureBox at runtime. If the CommandBars isn't on the form, it works as expected. However, when the CommandBars is on the form, changing the Width property of the PictureBox doesn't do anything: no visible change, and if I set the Width, then read it back, it's unchanged.

A small project that demonstrates the problem: Create a new VB6 project that contains an MDIForm. On the MDIForm, put a CommandBars control named CommandBars and a PictureBox named Picture1. Set the Align of Picture1 to Align Left and the Width to 2000. Put a CommandButton named Command1 inside Picture1, near the upper-left.

If you remove the CommandBars from the form and comment out the lines that reference it, it works as expected: Clicking the button toggles the PictureBox width between two sizes. With CommandBars, clicking the button doesn't do anything, and the Debug message says "Set to 1000, actual width is 2004"

SuitePro 22.0.0 on Windows 11.