[mol]

'Kujo' wrote:

The same problems are also visible with TEasyListview from MustangPeak.

In fact, this problem is visible in all Mustangpeak components; including VirtualExplorerEasyListview where the header isn't skinned at all and you end up with a stack overflow when closing the program.

The debugger stops with a message saying “…exception class EOutOfResources with message 'Invalid window handle' “, and points to line 184 of sVclUtils.pas

[mol]

http://code.google.com/p/virtual-treeview/downloads/list

[mol]

Interesting. If I recall correctly there had been problems with flickering before, though not in combination with AlphaControls. It had to do with the refresh of the application hint. Didn't the VST people just recently make changes to the Application.Hint call? Maybe worth to check.

[mol]

Try the attached demo. It doesn't show the behavior you've described.

Delphi 2010 Pro

Vista Home Premium 32bit

VST version 4.8.6

Latest AlphaControls

[mol]

Hm, I use VST extensively and I've never had any problems with it. Have you tried an earlier version of VST yet?

[mol]

'Kujo' wrote:

…there is a new big problem: the component flickers continually

How do you fill the tree? Are you refreshing the nodes in a loop?

[mol]

'ralfiii' wrote:

And a TFrame is missing the OnPaint-event which I need.

I usually use this approach: http://www.delphipages.com/forum/showthread.php?t=118316

[mol]

I know this doesn't resolve the bug, but still (out of curiosity): why do you guys use forms and not TFrames?

[mol]

TFrame1(sFrameBar1.Items[0].Frame).Edit1.Text := 'Hello'

[mol]

The bug is fixed in 8.04. Thanks, Serge!

[mol]

Serge, I tried but unfortunately I cannot pinpoint or reproduce the memory error with the test project just yet. After some major debugging in my main application it seems though that the problem boils down to a combination of several things. The first one being the following call

if TFrame2(FFrame).WebBrowser1.Busy then

TFrame2(FFrame).WebBrowser1.Stop;

and the other one being a memory issue where the debugger points to two calls to EnhMetaFile and TBitmap.LoadFromResourceName. This memory issue is the one that disappears once I take TWebBrowser off the ThirdPartyList.

Sorry that I cannot be of any further help at the moment.

[mol]

Okay, give me a day or two to come up with something.

[mol]

Serge, I tested your demo:

1. Maximizing the application, minimizing it, and then restoring it by clicking on its Taskbar button works now.

2. If I maximize the application, click on the 'Show Desktop' button on the Taskbar, and then on the application's Taskbar button again, your demo is maximized but its title bar is almost invisible (see attached screenshot).

[mol]

Yes, I can reproduce this bug. It's actually not a memory leak, but a memory error. FastMM reports the following (excerpt):

---

FastMM has detected an error during a GetMem operation. FastMM detected that a block has been modified after being freed.

Modified byte offsets (and lengths): 768(8), 808(8), 824(16)

The previous block size was: 1020

This block was previously allocated by thread 0xFF0, and the stack trace (return addresses) at the time was:

404532

449349

4495FA

449568

44F6D2

4493DE

4495FA

449539

44F6D2

44A4D6

446FC3

The block was previously used for an object of class: TWebBrowser

The allocation number was: 1220828

The block was previously freed by thread 0xFF0, and the stack trace (return addresses) at the time was:

40454E

906026

7E9EC9

4E8F8D

7E9AE0

4EC7E1

79318F

4EC553

450796

7643FD72 [Unknown function at GetWindowLongW]

7643FE4A [Unknown function at GetWindowLongW]

---

Does this help? If not, I will try to prepare a demo for you.

Thx

-mol

[mol]

You saw this, Serge?

[mol]

You're right, Hamilton. Never noticed that before.

[mol]

Great, thank you! Just make sure to free all allocated memory blocks. I ran into an AV the other day when freeing a TFrame holding a TWebBrowser. The error disappeared when I removed TWebBrowser from the ThirdPartyList of the sSkinManager.

[mol]

Hi Serge

I found the problem. If you load a page from the Internet like in your demo, the skinning works. If you load a file from your local hard drive (see my attached demo), then skinning doesn't work.

EDIT:

Just tested your demo with a local file: no skinning either…

-mol

[mol]

'Support' wrote:

TWebBrowser type should be added in the ThirdParty list as 'WebBrowser'. You did it? Other controls are skinned?

Yes, I added the TWebBrowser to the Thirdparty List, but the control (the scrollbars for example) isn't skinned. I'm using a TWebBrowser on a TFrame which is created at runtime, if that helps.

All other controls are skinned properly, as far as I can tell.

[mol]

Slow repainting. It's most noticable when scrolling up.

[Author]

Posts