Codejock Developer Community : 17.2 First pass

17.2 First pass : ok, I asked because this behavior...

Fri, 10 Jun 2016 12:49:33 +0000

Author: olebed
Subject: 23003
Posted: 10 June 2016 at 12:49pm

ok, I asked because this behavior was introduced more than 9 years ago
I will fix this.

17.2 First pass : Current behavior iterates each...

Fri, 10 Jun 2016 12:29:46 +0000

Author: Algae
Subject: 23003
Posted: 10 June 2016 at 12:29pm

Current behavior iterates each line and returns the maximum width of the lines.

Example: A text file of 100 lines with one really wide line of 2000 characters will return a max width of 2000 + some padding.

The scroll bar adjusts properly to accommodate.

However, as you observed, if that line width decreases, say by 100 characters, the max width should shrink to fit but it never does.

In that case the scroll bar does not adjust correctly as you observed.

One of my first attempts at fixing the behavior was to set m_nHScrollMaxWidth as you illustrated.

See this post:

http://forum.codejock.com/forum_posts.asp?TID=22827&title=recalcscrollbars-doesnt

I abandoned the change because it seemed to require a lot more calculation and made editing significantly slower.

17.2 First pass : Algae, I see how this works. I...

Fri, 10 Jun 2016 05:20:52 +0000

Author: olebed
Subject: 23003
Posted: 10 June 2016 at 5:20am

Algae, I see how this works. I asked about current behavior of m_nHScrollMaxWidth. It increases everytime 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 ?

17.2 First pass : The control scroll width initializes...

Thu, 09 Jun 2016 12:46:01 +0000

Author: Algae
Subject: 23003
Posted: 09 June 2016 at 12:46pm

The control scroll width initializes properly. The code is basically OK, until you load another file into the control.

Once past initialization the width does not reset to 0 when you load a new file into the control and uses the previous max value which is cumulative.

To duplicate:

1. Open the control
2. Load a disk text file with lines of varying lengths.
3. Result is correct. The control scroll width will be appropriate. Neither too wide nor too narrow.
4. Do not close the control.
5. Load another disk text file with lines of shorter lengths than the first file.
6. Result is incorrect. The scroll width retains the max width from step 2.

To solve, each time a different text file is loaded into the control, the max scroll width has to be reinitialized prior to loading.

Hence, a call to set max width to 0 should be made before loading a new file so it recalculates:

void ResetScrollMaxWidth() {m_nHScrollMaxWidth = 0;}

It makes a lot more sense than destroying the control and re-creating it each time you want to load a new file.

17.2 First pass : HelloAlgae, Algae wrote:2. Syntax...

Thu, 09 Jun 2016 07:59:46 +0000

Author: olebed
Subject: 23003
Posted: 09 June 2016 at 7:59am

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

17.2 First pass : I've tested the Calendar...

Fri, 22 Apr 2016 08:43:00 +0000

Author: Marco1
Subject: 23003
Posted: 22 April 2016 at 8:43am

I've tested the Calendar demo for five minutes on my Surface Pro 3.
It seems that there's still a big problem in scaling the fonts of the calendar events according to the enhanced DPI. This is pretty disappointing.
Further Office 2010 and 2013 themes still have some styling quirks on a Highres screen.

Please buy yourself a Surface or at least an appropriate high DPI monitor and test ALL your demos before releasing the next update.

Even our old - and still used - 15.3 version renders better on a Surface as the actual 17.2

Really hope you fix this urgent(!!), cause Toolkit Pro is slightly getting a show stopper for our product.

17.2 First pass : 1. Include static Unicode lib...

Mon, 18 Apr 2016 23:49:57 +0000

Author: Algae
Subject: 23003
Posted: 18 April 2016 at 11:49pm

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.