Author Topic: CDRF_DODEFAULT Problem on SysTreeView32  (Read 1950 times)

guga

  • Member
  • ****
  • Posts: 826
  • Assembly is a state of art.
    • RosAsm
CDRF_DODEFAULT Problem on SysTreeView32
« on: November 10, 2015, 02:53:46 PM »
Hi guys

I´m having trouble with a customdraw control that uses SysTreeView32 (On a regular window not inside a dialog)

I read the example of a listview http://masm32.com/board/index.php?topic=279.0  but when trying to set the control the notification message is not working. The same example can be found here http://www.dreamincode.net/forums/topic/283055-masm-custom-draw-listview-and-header

The notification message only goes to CDDS_PREPAINT and never on CDDS_ITEMPREPAINT

Someone have a working example of a treeview control that uses it ?
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

ToutEnMasm

  • Member
  • *****
  • Posts: 1189
    • EditMasm
Re: CDRF_DODEFAULT Problem on SysTreeView32
« Reply #1 on: November 10, 2015, 06:49:46 PM »

must be your include files,I have recompiled it with the translated sdk header files,the notification message
work perfectly.
Fa is a musical note to play with CL

guga

  • Member
  • ****
  • Posts: 826
  • Assembly is a state of art.
    • RosAsm
Re: CDRF_DODEFAULT Problem on SysTreeView32
« Reply #2 on: November 11, 2015, 01:18:41 AM »
Hi tout

thanks

the file worked fine on a listview, but i wasn´t being able to make it work on a SysTreeView32. The problem was on the main windowproc, when the notification message was sent i forgot to save the returned value. I fixed it like this:

Code: [Select]
Proc CallStackProc:
    Arguments @handle @Message @wParam @lParam
    Local @TmpReturn

    pushad

    .If D@Message = &WM_CREATE
(...)
    .Else_if D@Message = &WM_NOTIFY

        call CallStackDialog_OnNotify D@lParam
        mov D@TmpReturn eax | popad | mov eax D@TmpReturn | ExitP ; <--- Preserve the returned value and Exit the function
(...)
    .Else
        popad
        call 'User32.DefWindowProcA' D@handle D@Message D@wParam D@lParam
        ExitP
    .EndIf

    popad
    mov eax &FALSE

EndP


Code: [Select]
Proc CallStackDialog_OnNotify:
    Arguments @NotifyMsg

    mov ebx D@NotifyMsg
    mov eax D$ebx+NM_CUSTOMDRAWINFO.hwndFromDis

    ..If eax = D$CallStackTreeHandle

        .If D$ebx+NM_CUSTOMDRAWINFO.codeDis = &NM_CUSTOMDRAW

            mov eax D$ebx+NM_CUSTOMDRAWINFO.dwDrawStageDis ; draw stage
            If eax = &CDDS_PREPAINT
                mov eax &CDRF_NOTIFYITEMDRAW
            Else_if eax = &CDDS_ITEMPREPAINT
                call CallStackDialog_OnPaintItem D@NotifyMsg ; <--- Wahoo ! Debugged finally trigged :)
            Else_If_Or eax = &CDDS_SUBITEM, eax = &CDDS_ITEMPREPAINT
                call CallStackDialog_OnPaintItem D@NotifyMsg ; Here it seems to never stop. Probably because CDDS_SUBITEM does not exists on a treeview ? Note for me: Check later. Minor fix to remove this line of code
            Else
                mov eax &CDRF_DODEFAULT
            EndIf

        .ElseIf D$ebx+NM_TREEVIEW.hdr.codeDis = &TVN_SELCHANGED
            call CallStackForm_OnTreeNavigate ebx
            mov eax 0

        .Else
            mov eax 0
        .EndIf

    ..Else
        mov eax 0
    ..End_If

EndP

Code: [Select]
Proc CallStackDialog_OnPaintItem:
    Arguments @NotifyMsg
    Uses ebx

    mov ebx D@NotifyMsg
    mov eax D$ebx+NM_CUSTOMDRAWINFO.lItemlParamDis ; item param
    If eax <> 0

        mov al B$eax+CSE_Flags
        Test_If al CSEF_EXTERNAL
            mov D$ebx+NMTVCUSTOMDRAW.clrTextDis {RGB 102 102 102} ; set text color to gray
        Test_End
        Test_If D$ebx+NMTVCUSTOMDRAW.uItemStateDis &CDIS_SELECTED
            mov D$ebx+NMTVCUSTOMDRAW.clrTextDis {RGB 255 255 255} ; set text color to white
        Test_End

    EndIf
L0:
    mov eax &CDRF_NEWFONT

EndP


I´m updating a couple of things in RosAsm and this one is part of the debuger window. On the tab window that displays the call stack of the data collected when the file is being debugged, the treeview itens that was located outside the debugged module, was not being grayed. Now they are working :)

I´m also implementing the ability to dump the loaded memory (selected in parts of 4096 bytes) or completelly dump a module loaded in memory.

And, i finally succeeded to make it debugg huge files loaded in memory or huge loaded module in memory. For example, i can now test a plugin for Sony Vegas without Rosasm crash. I open a dll in rosasm, for example, and set sony vegas as the host and voilá, it loads correctly :)

On Sony Vegas, for example, while loading it causes some exception on their plugins as default. (As seen when using ollydbg, for example). Now when loading it on RosAsm, it simply bypass the exceptions to the app and it lists perfectly the modules/addresses and the addresses region in memory that causes the exception. (It works even when Sony is using a packed plugin, such quicktime ones).

I should finish some minor issues thie week before releasing it.


One problem i´m facing is with speed. Although i tried tyo optimize a bit the routines, it is kinda slow when populating the whole treeview with let´s say, 4000 itens and thousands of subitens. The windows that holds the treeview is a bit slow before displaying the whole tree. I wonder if there is a way to make it be faster.
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

fearless

  • Member
  • ***
  • Posts: 281
    • LetTheLightIn
Re: CDRF_DODEFAULT Problem on SysTreeView32
« Reply #3 on: November 11, 2015, 08:01:39 AM »
One problem i´m facing is with speed. Although i tried tyo optimize a bit the routines, it is kinda slow when populating the whole treeview with let´s say, 4000 itens and thousands of subitens. The windows that holds the treeview is a bit slow before displaying the whole tree. I wonder if there is a way to make it be faster.

I used to face a similar problem years ago programming with Visual Foxpro using Treeviews and having lots of subitems. Best way to handle this - (if its possible to do so, depending on your programs requirements, and what is too be seen by user) is to handle item expanding and populate the subitems then, this will speed up the whole treeview loading up and makes it appear that the data was there all along.

The best way to handle this is to put a dummy child item into the branches that will have data in them (you'll need some of way of knowing this beforehand). By adding a dummy child item (special name or entry to identify it as a dummy item) this will automatically show as a + sign on the node indicating to the user that they can expand this to see more child items.

In the item expanding method / msg, check for a dummy item (say a name like '__#DUMMY'), if found, you delete your dummy child item and load up the subitems. I used to use the lparam field of the node to indicate something that you can search for or relate to the data to fetch. I used to do that with says customer orders. lparam stored the customer id, so when node was expanded, delete dummy, query data, load child with info. you could set lparam as -1 perhaps for the dummy child item.

Hope that helps.
fearless

CM690II Case, HX1000 PSU, Asus Z97, Intel i7-4790K, Seidon 120v Cooler, 16GB DDR3, MSI GTX 980TI, Samsung 256GB + 1TB SSD, WD Black 2TB x2 + 4TB HDD, Asus 27" LCD

www.LetTheLight.in  My Github

guga

  • Member
  • ****
  • Posts: 826
  • Assembly is a state of art.
    • RosAsm
Re: CDRF_DODEFAULT Problem on SysTreeView32
« Reply #4 on: November 11, 2015, 10:00:52 PM »
Thanks, fearless.

I´ll give a try and see if i can implement it on the actual code. Not sure what may happens, since the debugger collect the data when the window that contains the treeview is on clicked. Don´t know what will happens if i hide all data or force the items to display only on user choice. Probably the data will be changed while debugging. But  i´ll test :)

Btw: Guys, i suceeded to improve RosAsm´s disassembler a lot. Now it is 10x faster then it was before. I tested on a app called PristonTale which contains internally thousands of nested code/data which made the disassembler to take a long time before the improves. Now, i can load it and it disasm in only 42 seconds on a file with 4.1 Mb. I´ll continue trying to improve it before i upload. I need to check if i didn´t breake anything  :greensml:
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

ToutEnMasm

  • Member
  • *****
  • Posts: 1189
    • EditMasm
Re: CDRF_DODEFAULT Problem on SysTreeView32
« Reply #5 on: November 12, 2015, 07:35:26 PM »
I have re-find (it was lost on the forum) a nice treeview demo written by Ewayne Wagner
I have modify it to accept Unicode or Ansi version.
Fa is a musical note to play with CL