A Generic ownerdraw system for DCBROWSE

[rdonnay]

I also noticed that 'up' or 'down' key pressed for few seconds, do the same. But only in network environment.

I would have suspected that those keys would do the same if my theory is correct.
Apparently, it is taking too long to load the array with information from the database when accessing via the network.
This would likely cause the event queue to fill up.

Try adding the following code to the top of METHOD XbpOwnerDrawBrowseGeneric:customDrawCell( oPS, aInfo ) in OWNERGEN.PRG.

Code: Select all

IF !::lOwnerDraw // ownerdrawing is switched off, let the system draw
  RETURN .T.
ENDIF

// <<<<<<< start
nEvent := NextAppEvent(@mp1,@mp2,@oXbp)

IF nEvent == xbeM_Wheel
  RETURN .t.
ELSEIF nEvent == xbeP_Keyboard .AND. mp1 $ { xbeK_UP, xbeK_DOWN }
  RETURN .t.
ENDIF
// <<<<<<<< end

You will also need to add #include "appevent.ch" at the top of the file.

[c-tec]

Hello,
here also on local machine, so not network related
regards
Rudolf

[Janko]

Roger,

I tested it and could not generate an error. EXE localy is running approximately with same speed as before, but EXE in network is refreshing OWNERDRAW browsers significantly slower, sometimes with errors in coloring. I did test remotely, tomorrow I intend to test it live, and will comment. I wonder if Rudolf succeded to solve his case.

Thank you
Best regards
JAnko

[Janko]

Roger,

sorry, yesterday I was testing browser remotely. Today, I did it again live in network environment and application froze again. Image in attachment.

Waiting for another solution
Janko

[rdonnay]

I don't know how I can help you if i cannot reproduce this.
I will try to simulate a slow network in the test application by putting some sleep() calls in the code.
Maybe I can reproduce the problem this way.

[Zdeno Bielik]

Roger,

I will try to simulate a slow network in the test application by putting some sleep() calls in the code.

or try install CpuKiller http://www.cpukiller.com – sometimes I used this for similar tasks - it worked super!
It is shareware-30day trial, but for your tests may be it is enough.

Zdeno

[rdonnay]

No matter what I do, I cannot get it to lock up.
Someone needs to give me an .EXE that has the lockup problem so I can verify that it will lockup on my computer.

[Auge_Ohr]

or try install CpuKiller http://www.cpukiller.com – sometimes I used this for similar tasks - it worked super!

it is not the CPU ...

Ownerdraw is too slow, special when "paint much", so timeing will not match Windows Queue which is running in GUI-Thread.
same have happend with VB ... this is why M$ does not use Ownerdraw ( old NT Standard ) and more but "real" Customdraw e.g. Listview, TreeView.

Code: Select all

      oLv:SetLvNotifyCB( NM_CUSTOMDRAW , {|o,notify_code,lp| oLv:OnCustomDraw(lp) } ) 

p.s. Xbase++ use GDI for 2D Render not 3D or DirectX. Xbase++ does not use 2D Hardware Acceleration.

most modern GFK does have a "bad" 2D Engine ... special Nvidea
onboard GFK Chip like 2D GPU Intel HD 4600 have much better 2D Performance Benchmark

[Janko]

Roger,

I've sent you to your private mail a link to my dropbox with EXE and PRGs.

Best regards
JAnko

[rdonnay]

I got all your files but this is turning into a real big project for me and it's not even an eXpress++ problem. The generic ownerdraw stuff I posted was a Sample program, not a new eXpress++ feature.

I think that it's time to get Alaska Software involved in this discussion.
Maybe they can shed some light on a solution.