Hi Oliver,
On Thu, Mar 29, 2012 at 7:18 AM, Oliver Sims <oliver.sims@simsassociates.co.uk> wrote:
I've got a List View (subclassed from RcDialog) with three columns where I set styles in intiDialog as follows:
lvCustomers = self~newListView("IDC_CUSTLIST_LIST");
lvCustomers~addExtendedStyle(GRIDLINES FULLROWSELECT)
I noticed that when I clicked the column headers, nothing happened - although the headers sort of look like buttons, and when clicked appear to be depressed like buttons. This didn't surprise me. So to avoid giving the user the idea that something wasn't working, I thought to suppress at least the look & feel of the headers by adding, immediately after the ~addExtendedStyle()
statement (I also tried immediately before) the following:
What is not obvious is that, for almost every control, some styles can be changed after the control is created, but many styles can not be changed after the control is created.
This is one of them.  The style has to be present in the .rc file (in this case.)  For a UserDialog the style would need to be present in the createListView() method.  I just changed it manually, and it works as you expected.  In the .rc file use this:
Also, I discovered you have a bug in your code.  Actually in 2 places, but the same thing.  You have this line in the init() method for 2 of the dialog classes:
    menuBar = .ScriptMenuBar~new("Customer\CustomerListView.rc", "IDR_CUSTLIST_MENU", , , .true, self)
The self argument is arg 6, the attachTo argument.  You can not attach a menubar to a dialog until the underlying dialog exists.  So attach to needs to be done in initDialog(), which you are already doing.  In the same dialog class you have in initDialog():
    -- Called by ooDialog after SHOWTOP.
Menus in 4.2.0 are independent objects, so you can create a menu anywhere, but you can only attach a menubar after the underlying Windows dialog exists.
This was probably just a misunderstanding you had since I didn't have any of the documentation done. 
Right now in trunk a condition is raised, so the raised condition could be due to a recent change in the Menu classes implementation.  I have documented about 65% of the menu stuff now. 
As I document it, I've been fixing some things that were not right.  The code would always have been an error, but it's possible that I had missed raising the condition.  All the new() methods for the menu classes are supposed to raise a condition on any error, so that, if there is no condition you can be sure the menu was created as you expected.
I expected to see a visible difference in the dialog appearance and header-click behavior. But there was no perceptible difference. 
Am I misreading the ooDialog reference, or is there a bug?
Probably neither.  It is impossible for me to test every tiny nuance of behavior.  Well, maybe not forever, but a really, really long time.  ;-) 
The bulk of the documentation comes from what Microsoft documents.  In this case they do not mention that the style can not be changed after the control is created and other styles on the same page of the Microsoft documentation can be changed.  So, the ooDialog documentation is as good as the Microsoft documentation.
Mark Miesfeld