Retrieving ReportView Column Headers

Started by mhall, March 26, 2014, 03:16:41 AM

Previous topic - Next topic


Hi All,

Currently I'm working with the ReportView control for the first time and I'm getting acquainted with it.

I'm retrieving the Column Headers using dialogControlGet request code 20 as the documentation suggests. This works ... unless I drag and drop change the column order. I get a value back, but it is the original order of the columns, not the changed order.

I'm using 2012B at the moment. Have a newer version on my office machine but don't have access for the next week and a half to see if it is the same there.

Can anyone confirm they get the correct order of column headers back? It's 3am, I'm a little tired and throwing in the towel. Perhaps I'll make sense of it in the morning. :)



I wasn't aware the Reportview control allowed drag and drop of columns. Lets see a code sample.
Deana F.
Technical Support
Wilson WindowWare Inc.


Hi Deana,

According to the docs I have here it's DialogControlState style 268435456.

Enables drag-and-drop reordering of columns in the control.

Using the built in Dynamic Dialog constants, I used:

dialogControlState( requestInfo_Handle, 'ReportView_RequestList', DCSTATE_ADDSTYLE, DCSTYLE_REORDERCOL )

Here's a simple Dialog:

#defineSubRoutine displayFruit()

FruitCaption=`I Love Fruit`





#DefineSubRoutine InitDialogConstants()
   ;DialogprocOptions Constants
   MSG_INIT=0                    ; The one-time initialization
   MSG_TIMER=1                   ; Timer event
   MSG_BUTTONPUSHED=2            ; Pushbutton or Picturebutton
   MSG_RADIOPUSHED=3             ; Radiobutton clicked
   MSG_CHECKBOX=4                ; Checkbox clicked
   MSG_EDITBOX=5                 ; Editbox or Multilinebox
   MSG_FILESELECT=6              ; Filelistbox
   MSG_ITEMSELECT=7              ; Itembox
   MSG_COMBOCHANGE=8             ; Combobox/Droplistbox
   MSG_CALENDAR=9                ; Calendar date change
   MSG_SPINNER=10                ; Spinner number change
   MSG_CLOSEVIA49=11             ; Close clicked (Enabled via DialogProcOptions 1002
   MSG_FILEBOXDOUBLECLICK=12     ; Get double-click message on a FileListBox
   MSG_ITEMBOXDOUBLECLICK=13     ; Get double-click message on an ItemBox
   MSG_COMEVENT=14               ; COMCONTROL Event notification from DialogObject (NOT DialogProcOptions)
   MSG_MENUITEM=15               ; MenuItem selected
   MSG_MENUITEMINIT=16           ; MenuItem initialized
   MSG_RESIZE=17                 ; Dialog resized
   MSG_RVITEMSELROW=18           ; Reportview item select row
   MSG_RVDBLCLICKROW=19          ; Reportview double-click row
   MSG_RVCHECKEDITEM=20          ; Reportview checked/unchecked Item
   MSG_RVITEMTEXT=21             ; Reportview item text

   DPO_DISABLESTATE=1000         ; codes -1=GetSetting 0=EnableDialog 1=DisableDialog
   DPO_CHANGEBACKGROUND=1001     ; -1=Get Current otherise bitmap or color string
   DPO_CHANGESYSMENU=1002        ; -1=Get Current 0=none 1=close 2=close/min 3=close/max 4=close/min/max
   DPO_CHANGETITLE=1003          ; Set/Get Dialog Title - (-1 to get)
   DPO_GETNAME=1004              ; Returns the name associated with a control's number.
   DPO_GETNUMBER=1005            ; Returns the number associated with a control's name.
   DPO_GETCLIENTAREA=1007        ; Returns a space delimited list of the width and height of the client area.

   ;DialogControlState Constants
   DCSTATE_SETFOCUS=1            ; Give Control Focus
   DCSTATE_QUERYSTYLE=2          ; Query control's style
   DCSTATE_ADDSTYLE=3            ; Add control style
   DCSTATE_REMOVESTYLE=4         ; Remove control style
   DCSTATE_GETFOCUS=5            ; Get control that has focus
   DCSTATE_MOVEMOUSEOVER=6       ; Move the mouse over the control

   DCSTYLE_DEFAULT=0             ; Set Default Style
   DCSTYLE_INVISIBLE=1           ; Set Control Invisible
   DCSTYLE_DISABLED=2            ; Set Control Disabled
   DCSTYLE_NOUSERDATA=4          ; Note: Setable via DialogControlState function ONLY SPINNER control only
   DCSTYLE_READONLY=8            ; Sets control to read-only (user cannot type in data) EDITBOX MULTILINEBOX SPINNER
   DCSTYLE_PASSWORD=16           ; Sets 'password mode' where only *'s are displayed EDITBOX
   DCSTYLE_DEFAULTBUTTON=32      ; Sets a button as the default button PUSHBUTTON PICTUREBUTTON
   DCSTYLE_DIGITSONLY=64         ; Set edit box to accept digits only EDITMOX MULTILINEBOX
   DCSTYLE_FLAT=128              ; Makes a 'flat' hyperlink-looking button PUSHBUTTON PICTUREBUTTON
   DCSTYLE_NOADJUST=256          ; Turns off auto-height adjustment  ITEMBOX FILELISTBOX
   DCSTYLE_TEXTCENTER=512        ; Center text in control VARYTEXT STATICTEXT
   DCSTYLE_TEXTRIGHT=1024        ; Flush-Right text in control VARYTEXT STATICTEXT
   DCSTYLE_NOSELCURLEFT=2048     ; No selection, cursor left EDITBOX MULTILINEBOX
   DCSTYLE_NOSELCURRIGHT=4096    ; No selection, cursor right EDITBOX MULTILINEBOX
   DCSTYLE_SHIELD=8192           ; Display Security Shield icon on button (Vista only) PUSHBUTTON PICTUREBUTTON
   DCSTYLE_MENUCHECK=32768       ; Adds a check mark to the left of a menu item MENUITEM
   DCSTYLE_MENURADIO=65536       ; Adds a radio button like dot graphic to the left of a menu item MENUITEM
   DCSTYLE_MENUSEP=131072        ; Separator bar graphic MENUITEM
   DCSTYLE_MENUBREAK=262144      ; Column break MENUBAR
   DCSTYLE_NOHEADER=524288       ; No header bar REPORTVIEW
   DCSTYLE_COLHEADER=1048576     ; First row column header REPORTVIEW
   DCSTYLE_GRIDLINES=2097152     ; Grid lines REPORTVIEW
   DCSTYLE_SELONEROW=4194304     ; Only one row can be selected at a time REPORTVIEW
   DCSTYLE_SELALLROW = 8388608   ; Highlight complete row REPORTVIEW
   DCSTYLE_SORTASC=16777216      ; Ascending sort REPORTVIEW
   DCSTYLE_SORTDESC=33554432     ; Descending sort REPORTVIEW
   DCSTYLE_EDITCOL=67108864      ; Edit first columns text REPORTVIEW
   DCSTYLE_COLCHECKBOX=134217728 ; Add checkbox to first column REPORTVIEW
   DCSTYLE_REORDERCOL=268435456  ; Drag-and-drop reordering of columns REPORTVIEW

   ;DialogControlSet / DialogControlGet Constants
   DC_CALENDAR=7             ; CALENDAR
   DC_SPINNER=8              ; SPINNER
   DC_HANDLE=19              ; ALL CONTROLS (Except MENUBAR and MENUITEM)

   ;DialogObject constants
   DLGOBJECT_ADDEVENT=1      ; Call dialog callback when the specified event occurs
   DLGOBJECT_STOPEVENT=2     ; Stop calling dialog callback when an event previously requested with
   DLGOBJECT_GETOBJECT=3     ; Return an object references to the specified control
   DLGOBJECT_GETPICTURE=4    ; Create and return an object reference to a picture object

   ;Return code constants
   RET_DO_CANCEL=0           ; Cancels dialog
   RET_DO_DEFAULT= -1        ; Continue with default processing for control
   RET_DO_NOT_EXIT= -2       ; Do not exit the dialog

InitDialogConstants()                                       ; Initialize Dialog Constants (need only be done once usually)

#DefineSubroutine FruitCallbackProc(Fruit_Handle,Fruit_Message,Fruit_Name,Fruit_EventInfo,Fruit_ChangeInfo)
   ON_EQUAL = @TRUE                                         ; Initialize variable ON_EQUAL
   switch Fruit_Message                                     ; Switch based on Dialog Message type
      case MSG_INIT                                         ; Standard Initialization message
;         DialogProcOptions(Fruit_Handle,MSG_TIMER,1000)
;         DialogProcOptions(Fruit_Handle,MSG_BUTTONPUSHED,@TRUE)
;         DialogProcOptions(Fruit_Handle,MSG_RVITEMSELROW,@TRUE)
;         DialogProcOptions(Fruit_Handle,MSG_RVDBLCLICKROW,@TRUE)
;         DialogProcOptions(Fruit_Handle,MSG_RVCHECKEDITEM,@TRUE)
;         DialogProcOptions(Fruit_Handle,MSG_RVITEMTEXT,@TRUE)

dialogControlState( Fruit_Handle, 'ReportView_FruitView', DCSTATE_ADDSTYLE, DCSTYLE_SELONEROW )
dialogControlState( Fruit_Handle, 'ReportView_FruitView', DCSTATE_ADDSTYLE, DCSTYLE_SELALLROW )
dialogControlState( Fruit_Handle, 'ReportView_FruitView', DCSTATE_ADDSTYLE, DCSTYLE_REORDERCOL )
dialogControlState( Fruit_Handle, 'ReportView_FruitView', DCSTATE_ADDSTYLE, DCSTYLE_GRIDLINES )
dialogControlState( Fruit_Handle, 'ReportView_FruitView', DCSTATE_ADDSTYLE, DCSTYLE_COLHEADER )

dialogControlState( Fruit_Handle, 'ReportView_FruitView', DCSTATE_ADDSTYLE, DCSTYLE_REORDERCOL )

dialogControlSet( Fruit_Handle, 'ReportView_FruitView', DC_ITEMBOXCONTENTS, arr_Fruit )


;        if Fruit_Name == "PushButton_OK"                   ; OK
;              return(RET_DO_DEFAULT)

;        elseif Fruit_Name == "PushButton_Cancel"           ; Cancel
;              return(RET_DO_DEFAULT)

;        endif                                              ; Fruit_Name
;        return(RET_DO_DEFAULT)

;     case MSG_RVITEMSELROW                                 ; ID "ReportView_1"  rvVariable1
;        return(RET_DO_DEFAULT)

   endswitch                                                ; Fruit_Message
#EndSubroutine                                              ; End of Dialog Callback FruitCallbackProc


arr_Fruit = arrDimension( 4, 5 )
arrInitialize( arr_Fruit, '' )

arr_Fruit[ 0, 0 ] = 'Name'
arr_Fruit[ 0, 1 ] = 'Color'
arr_Fruit[ 0, 2 ] = 'Peel Type'
arr_Fruit[ 0, 3 ] = 'Juicy'
arr_Fruit[ 0, 4 ] = 'Like it?'

arr_Fruit[ 1, 0 ] = 'Banana'
arr_Fruit[ 1, 1 ] = 'Yellow'
arr_Fruit[ 1, 2 ] = 'Non-edible'
arr_Fruit[ 1, 3 ] = 'No'
arr_Fruit[ 1, 4 ] = 'Sure!'

arr_Fruit[ 2, 0 ] = 'Apple'
arr_Fruit[ 2, 1 ] = 'Red/Yellow/Green'
arr_Fruit[ 2, 2 ] = 'Edible'
arr_Fruit[ 2, 3 ] = 'Hopefully!'
arr_Fruit[ 2, 4 ] = 'Absolutely'

arr_Fruit[ 3, 0 ] = 'Watermelon'
arr_Fruit[ 3, 1 ] = 'Watermelon'
arr_Fruit[ 3, 2 ] = 'Non-edible'
arr_Fruit[ 3, 3 ] = 'Yes'
arr_Fruit[ 3, 4 ] = 'Indeed!'



You must be using the beta.  The REPORTVIEW column drag/drop style was removed from the production release of 2012B.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade


Ah, I suspected but didn't see that in my PopMenu or WinBatch Editor About screens. I only use this machine when I travel and haven't updated it for a while.

Thanks. I'll be sure not to use that. But it'd be kinda handy! :)



You can do it via a couple of Win32 API DLL calls if you know what you are doing.. the order can get a bit confusing, hence probably why they dropped it officially in the Report View.


Nothing sucks more than that moment during an argument when you realize you're wrong. :)


Actually, there were multiple reasons for removing the column drag and drop functionality for the production release.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade


Moving those seems like one feature that would require the one thing requiring many other things so not surprised it was dropped...that and the point was to simply provide a "display" and not a "grid"....but, if I can chime in with a feature request since we are on the topic of Column Headers.   The one thing that I find an EXTREME hassle is the would be OH SO NICE if you would change it so that clicking on a header would sort asc and then clicking again would sort desc.   Having to manage that manually is not much fun and even have trouble understanding why it was implemented in such a fashion.  Guess it was just easy.   Can't think of a single situation where someone would want it to work the way it does and wouldn't want it to work the way I'm suggesting...but maybe I'm clueless, as often seems to be the case :)

Multiple column sorting would be nice but I know that is unlikely.



Jim, I personally like the ability to have MORE control over the Report View (or any GUI control for that matter), being able to capture the column-click event before any sorting takes place is GOOD... then I can implement some other routine rather than just the built-in sorting. (things like custom sorting, flagging a column was clicked to extract all sub-items in that column etc. etc.).

However, I agree that a quick default toggle between sort asc and dec would be a nice option to implement somehow... providing the above option was kept too. (but Jim, it's not that hard to change styles is it?)

One thing I really wish is that the whole ReportView thing used numerical indexing rather than the text based addressing of items (is that what you were referring to Jim? ;))

Nothing sucks more than that moment during an argument when you realize you're wrong. :)


I'm not saying to take stuff comments along this line were that the default behavior should be the asc/desc toggle.   Can't think of a single time when I would only want one [fixed] way of sorting and can't imagine anyone else wanting it that way either.   Makes no sense that EVERYONE has to program around this lacking or live with the deficiency because I think it would be hard to argue that it is NOT expected behavior in a grid display (yes WB folks, I know grid is a bad word in this discussion but that is the type of display it is).   Actually found myself trying to figure out what was wrong the other day when it wasn't sorting when I clicked on the header...took me a while to remember that it didn't work that way.

I know there are ways to work around such problems but this is one that people shouldn't HAVE to work around, easy or not, because the expected behavior of this type of display is a toggle sort.  I rarely make these points because I lack the imagination or the ability to solve such problems but because I love WinBatch and want it to be the best.  Stuff like this annoys me because it strikes me as a failure on the part of whoever designed/programmed it to do their best and therefore has made WinBatch less that what it could be.  Obviously many of us want new stuff but that isn't the point here...I don't consider this a "new" feature request...for me it falls more into a bug/design flaw category...when something is implemented it should work well, in an expected manner and make sense.  There are a handful of things like this in WinBatch and hence, the subjects of my occasional rants :)

Did you take a look at the extender I created?  It will allow you to use numerical indexing and affect cells.   Happy to send you the source code if you want to help expand that project.   You know far more than me about such things.



/EDIT/ .. Whoops.. you got me ranting too, and I think we've taken over this post... SORRY! :-[

No worries Jim.. I know what you mean.

I did look at your extender... it is nice and I may use it in the future, but up until now I have been able to use various Dll calls (my Listview UDF stuff) to do most of what I need with the Report View, and other similar tricks with other controls without the need for an additional extender being packaged into my compiled exe's. (I don't like extenders if I can avoid them).

I admire your efforts and honestly, you flatter me thinking I can expand on your extender...
While I might know a bit about the ListView control and some general Win32 API stuff, it's almost all been learnt via trial and error and mainly through need, when I thought things were lacking in WinBatch, and I wanted a way around it.
But most of my experiments were done via WinBatch itself, not as an extender made in C++ / Visual Studio.
Basically, I am not a C / C++ /C# programmer of any note at all, so writing or expanding the extender would be a challenge for me.
I have tried dabbling in C++ and even assembler a couple of times, but find it frustrating.. even setting up the environment and understanding how to compile things was a challenge if I remember correctly (errors complaining about missing libraries etc), let alone learning the new language constructs and syntax ...but, that was a few years ago... I might find it easier now?

That is why I persist in WinBatch... I know it, I'm pretty lazy and I can do most things in WinBatch that I need to do... I only get frustrated sometimes, but not enough to get me motivated enough to jump ship and learn / use a different language and IDE... but I might if WinBatch doesn't keep progressing along, and my needs change enough.

I guess I see and treat WinBatch a bit differently from what the developers of it do... rightly or wrongly...

I use it as almost a full programming language and create desktop applications with fairly complicated GUI interfaces with it, rather than just making simple middle-ware glue scripts to change a few settings and copy some files.
I see it like a syntactically feature-rich but simpler to use Visual Basic, or a more professional AutoIt  (but it lacks the GUI events and controls that these have).

That is why, like you, I would like to see enhancements in the GUI area I suppose, and the developers probably don't see the need.
I think WinBatch is a great product and could attract an even bigger user base if it were tweaked around the edges in this respect a bit more (as well as a few other places).
If I thought it would help, I would write a complete list of what I would like to see implemented, but I'm not sure it would be taken the right way or acted upon anyway... maybe it's me that needs to change and learn a new language and write an extender or just use a different language altogether?


Nothing sucks more than that moment during an argument when you realize you're wrong. :)


It looked like the thread was pretty much completed or I wouldn't have hijacked it.

Sounds like we do a similar thing with WinBatch.   My largest project I have going has grown to more than 126,000 lines with about 90 dialogs.  I have a couple of others that are probably around half that size or more.

I hadn't done any C programming for 20 years, and not much then, when I tackled the extender and put most of that together in a couple of weeks so it isn't as daunting as one might think, which of course makes me wonder why more things are implemented.   As I usually say, "If I can do it......".    You have a good grasp of data structures and that would be a plus.  I had to beat my head against the wall quite a bit on some parts related to those things and Google is my very good friend.

In any event, they do a great job at Windowware but that won't keep me from "encouraging" them to do better :)