17.2 First pass

1. Include static Unicode lib builds for samples. Avoid DLL h3LL. OK, it's easy enough to change the sample prog projects, but we should be modern .. and fast.. and not have clutter and I'm so tired of changing /MDd to /MTd. Even Microstuff says they only do Unicode now. Competitor does em' and it's an easy inclusion.

2. Syntax edit desperately needs:

void ResetScrollMaxWidth() {m_nHScrollMaxWidth = 0;} // Init the maximum horizontal scrollbar position.

Call it every time before loading a new edit file. If you don't, every file opened for edit uses the last file edited max width and that could be very wide indeed. This problem still exists. Please, it's such a simple thing! Otherwise the edit control is pretty good. Faster than many and has some very good features.

3. Heap Corruption. Whoever called this fixed must be working in a foreign language and didn't translate the error.

It has nothing to do with "Skin", "Theme" or such nonsense. It's in the code guys, not in the themes themselves. Still. I'd be very surprised if it's not in new DPI handling somewhere since it didn't happen before that.

"Windows has triggered a breakpoint in CalendarDemo.exe.
This may be due to a corruption of the heap, which indicates a bug in CalendarDemo.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while CalendarDemo.exe has focus.
The output window may have more diagnostic information."

Set ToolTip Custom, push the pointer over an Event.. and POW.. your program is done.

if ((tiHit.lpszText != LPSTR_TEXTCALLBACK) && (tiHit.hinst == 0))
     free(tiHit.lpszText);

I can duplicate this any time without any mods to code, direct from CalendarDemo sample. That cannot possibly be right.

That's as far as I got before abandoning 17.2 for my old hacked up 16.26. I'm not even going to start on TreeCtrl again because I know there was no fix for that. Nor have I tried the debacle which is Win 10 in any DPI. I haven't gotten out of debug on Win 7 with CJ 17+ yet. Sigh.

Thanks for listening and hope you can get it fixed up. Otherwise, I have to explain to my partner why the company needs to blow $ for subscriptions we can never use. Makes us tech types look like goofs.

CJ 17.2 - static
Win 7 Pro 64 bit
Visual Studio 2010

*Message includes no VM, no trans fats, no gluten. Plain ol' simple Windows stuff.

Hello Algae,

Algae wrote: 2. Syntax edit desperately needs: void ResetScrollMaxWidth() {m_nHScrollMaxWidth = 0;} // Init the maximum horizontal scrollbar position. Call it every time before loading a new edit file. If you don't, every file opened for edit uses the last file edited max width and that could be very wide indeed. This problem still exists. Please, it's such a simple thing! Otherwise the edit control is pretty good. Faster than many and has some very good features.

I checked this and found that m_nHScrollMaxWidth  set to 0 in constructor of CXTPSyntaxEditCtrl::CXTPSyntaxEditCtrl().

Also I found this code

void CXTPSyntaxEditCtrl::_RecalcHScrollMaxWidth() {     CRect rcText = m_pDrawTextProcessor->GetTextRect();     int nPageX = rcText.Width();     int nMaxX = m_pDrawTextProcessor->GetRowsMaxWidth();     nMaxX += max(nPageX/4, m_pDrawTextProcessor->GetTextMetrics().tmAveCharWidth * 20);     nMaxX = max(nMaxX, rcText.Width() * 2);     m_nHScrollMaxWidth = max(nMaxX, m_nHScrollMaxWidth); }

I don't know history of this control  and I doubt the last line. Should m_nHScrollMaxWidth always increase ?  Or should fit the real size of text and editor ?  I think

m_nHScrollMaxWidth = nMaxX;

will be better.

Regards,
 Oleksandr Lebed

Algae, I see how this works. I asked about current behavior of m_nHScrollMaxWidth. It increases every time when width of text increases, but don't decreases when width of text decreases. That is why m_nHScrollMaxWidth is so large. I propose to change last line in method CXTPSyntaxEditCtrl::_RecalcHScrollMaxWidth() with

m_nHScrollMaxWidth = nMaxX;

Will it be the expected behavior for you and other customers ?