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. :)
Regards,
Micheal
I wasn't aware the Reportview control allowed drag and drop of columns. Lets see a code sample.
Hi Deana,
According to the docs I have here it's DialogControlState style 268435456.
Quote
268435456
Enables drag-and-drop reordering of columns in the control.
REPORTVIEW
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()
FruitFormat=`WWWDLGED,6.2`
FruitCaption=`I Love Fruit`
FruitX=9999
FruitY=9999
FruitWidth=299
FruitHeight=203
FruitNumControls=003
FruitProcedure=`FruitCallbackProc`
FruitFont=`DEFAULT`
FruitTextColor=`DEFAULT`
FruitBackground=`DEFAULT,DEFAULT`
FruitConfig=0
Fruit001=`222,182,033,009,PUSHBUTTON,"PushButton_OK",DEFAULT,"OK",1,10,32,DEFAULT,DEFAULT,DEFAULT`
Fruit002=`255,182,032,009,PUSHBUTTON,"PushButton_Cancel",DEFAULT,"Cancel",0,20,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Fruit003=`030,036,241,102,REPORTVIEW,"ReportView_FruitView",rvVariable1,DEFAULT,DEFAULT,30,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
ButtonPushed=Dialog("Fruit")
#endSubRoutine
;============================================================
;============================================================
;============================================================
#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_CHECKBOX=1 ; CHECKBOX REPORTVIEW
DC_RADIOBUTTON=2 ; RADIOBUTTON
DC_EDITBOX=3 ; EDITBOX MULTILINEBOX
DC_TITLE=4 ; PICTURE RADIOBUTTON CHECKBOX PICTUREBUTTON VARYTEXT STATICTEXT GROUPBOX PUSHBUTTON MENUITEM
DC_ITEMBOXCONTENTS=5 ; ITEMBOX FILELISTBOX DROPLISTBOX REPORTVIEW
DC_ITEMBOXSELECT=6 ; ITEMBOX FILELISTBOX DROPLISTBOX REPORTVIEW
DC_CALENDAR=7 ; CALENDAR
DC_SPINNER=8 ; SPINNER
DC_MULTITABSTOPS=9 ; MULTILINEBOX
DC_ITEMSCROLLPOS=10 ; ITEMBOX FILELISTBOX
DC_BACKGROUNDCOLOR=11 ; RADIOBUTTON CHECKBOX VARYTEXT STATICTEXT GROUPBOX PUSHBUTTON ITEMBOX FILELISTBOX DROPLISTBOX SPINNER EDITBOX MULTILINEBOX REPORTVIEW
DC_PICTUREBITMAP=12 ; PICTURE PICTUREBUTTON
DC_TEXTCOLOR=13 ; RADIOBUTTON CHECKBOX VARYTEXT STATICTEXT GROUPBOX PUSHBUTTON ITEMBOX FILELISTBOX DROPLISTBOX SPINNER EDITBOX MULTILINEBOX REPORTVIEW
DC_ITEMBOXADD=14 ; ITEMBOX FILELISTBOX DROPLISTBOX REPORTVIEW
DC_ITEMBOXREMOVE=15 ; ITEMBOX FILELISTBOX DROPLISTBOX REPORTVIEW
DC_RADIOVALUE=16 ; RADIOBUTTON
DC_POSITION=17 ; ALL CONTROLS (Except MENUBAR and MENUITEM)
DC_MENUNAMES=18 ; ALL CONTROLS
DC_HANDLE=19 ; ALL CONTROLS (Except MENUBAR and MENUITEM)
DC_RVCOLHEAD=20 ; REPORTVIEW
DC_RVCOLWIDTH=21 ; REPORTVIEW
DC_RVCOLMATCH=24 ; REPORTVIEW
DC_RVCANCELEDIT=25 ; REPORTVIEW
DC_RVCHECKEDROWS=26 ; REPORTVIEW
;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
return
#EndSubroutine
;============================================================
;============================================================
;============================================================
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 )
return(RET_DO_DEFAULT)
; case MSG_BUTTONPUSHED
; 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
return(RET_DO_DEFAULT)
#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!'
displayFruit()
You must be using the beta. The REPORTVIEW column drag/drop style was removed from the production release of 2012B.
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! :)
~Micheal
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.
Actually, there were multiple reasons for removing the column drag and drop functionality for the production release.
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 sorting...it 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
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? ;))
I'm not saying to take stuff away...my 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.
Jim
/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?
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 :)
Jim