Listview column width question

[BOB MECHLER]

I want to be able to save the columnwidths as a user preference and can do so if they click a quit button by using

      FOR lCol = 0 TO lColCnt - 1
        lv_columnwidth(lCol) = ListView_GetColumnWidth( lv_hctl&, lCol)
      NEXT lCol
      'get horizontal scroll position
      lv_horzscroll& = GetScrollPos(lv_hctl&,%SB_HORZ)

That way the user has the columnwidths the way he wants them the next time to program is run. I'm of course having trouble if he click the red 'x' closing the window. I do manage to trap this event and run it through and end of job kind of shutdown but by that time the listview is destroyed and the most recently set columnwidths are gone.

In the WM_NOTIFY event what notification is given when the columns are resized by hand. If there is such a notification I can update the array of column widths on the fly as they adjust the columns.

Thanks in advance,

Bob Mechler

[Michael Mattias]

Just get and save the column widths on WM_DESTROY of parent window; all child windows may be assumed to exist on WM_DESTROY of the parent.

That's when I do it.


MCM

[BOB MECHLER]

Thanks. For some reason I thought the Window and it's elements would already be destroyed at that point.

Bob Mechler

[BOB MECHLER]

The WM_DESTROY message is sent when a window is being destroyed. It is sent to the window procedure of the window being destroyed after the window is removed from the screen. 

This message is sent first to the window being destroyed and then to the child windows (if any) as they are destroyed. During the processing of the message, it can be assumed that all child windows still exist.

You can see why I thought this since it says in the docs that the child windows can be assumed to still exist but where does that leave the window containing the listview that is being destroyed?

Actually I'd rather like to be able to save to an array the width preferences anytime they are changed. I believe I can trap a LBUTTONDOWN in the listview or use a HITTEST. I think I'd like more ideas here.

Bob Mechler

[Michael Mattias]

???

Why do you want to make your life difficult? A little streak of masochism?

You don't need to save the settings when the user changes them, because Windows remembers and uses them until the process ends.

Before your process ends, you tell Windows to destroy your windows;before Windows destroys a window, it sends a WM_DESTROY notification. (think about it: if your window no longer existed, how could you send a notification to it?)

WM_DESTROY is the de facto 'standard' for "when you save user window settings."

[BOB MECHLER]

Although I couldn't find a specific message for changing the column widths using the mouse, I did find a way without using WM_DESTROY to know when it was occurring. I just used a case else in WM_NOTIFY.

Bob Mechler

[Roger Garstang]

If you really want this, you will need to get the notify messages of the Header control which is a child of the listview. Perhaps the message HDN_ITEMCHANGED or HDN_TRACK. Michael is correct in the proper place to check for this though. No need to save the status a possible thousand times every couple seconds. The Case Else is in no way going to catch all possible cases either. The ItemChanged notification the Listview sends may work too. There is a way to capture Alt+F4 and clicking the X too, but in some cases the window can be closed without either of those and only the Destroy message is fired. As for the window being there or not a simple IsWindow check will work and is usually nice to do before sending a message to a handle anyway.

[BOB MECHLER]

Helpful hints Roger. I'll try them.

Wouldn't the case else only fire if over or interacting with the listview. That shouldn't be thousands of times. Anyway, there should be a way to trap it without using the wm_destroy event.

Bob Mechler

[Cliff Nichols]

I am confused....Isn't the %WM_DESTROY the last message sent to a "Dialog/Window"??? If it is then thats where you want to *.ini or other method to keep the "Last Known" settings so the next time things open as you wanted them?

Doing it as you change it....BAD IDEA because the number of times you are changing values, and depending on the system, and what the value is written to, can SUBSTANTIALLLY reduce your response time

case in point...try writing an ini to a floppy on every resize event.....see you Monday...

Sorry if it sounds harsh Bob, but take it from one just learning the concept myself....I been there, and done that....and thought I would save you the grief

[Michael Mattias]

Let's take this out of the realm of the objective and put it into the realm of the subjective....maybe that will convince you....

>Anyway, there should be a way to trap it without using the wm_destroy event.

And there is - if the listview control has a header (HDN_BEGINDRAG) - but for the purpose described (save user's last settings for use next time the program is run) it is IMNSHO totally silly to use anything but the WM_DESTROY notification.

[BOB MECHLER]

:Of course, in a normally structured program where each program had a unique dialog callback you guys are absolutely correct.

This particular program has a common message pump for all textboxes and a separate message pump for listviews that reacts to flags set in the WM_NOTIFY event.

The WM_DESTROY event is only used to Delete Objects like fonts. It is in a generic dialog call back that is common to all the programs. All WM_COMMAND stuff handled only menu items. All WM_NOTIFY stuff returned flags which are handled by a ListView message pump. That was ok when I wrote it way back when I was first learning PB but not now.

Before your posts, I did not know that the WM_DESTROY event could be used to catch settings and store them.

Maybe I should take the generic DIALOG.INC and create a special version of it for this program where the WM_DESTROY event is expanded to handle the Listview saving of preferences. Of course, if I need to make a change to the generic DIALOG.INC, I'll have to remember to change it for this one special instance also.

BOB MECHLER

[Michael Mattias]

Maybe I should take the generic DIALOG.INC ..

And change this...

This particular program has a common message pump for all textboxes and a separate message pump for listviews....

That was ok when I wrote it way back when I was first learning PB but not now.

.. to something more representative of your current, enhanced expertise (i.e, scrap it and start anew "knowing what you know now")?

MCM

[BOB MECHLER]

Truth be told, I have to maintain the programs that we have and enhance them while I'm in the process of completely revamping the basic skeleton where I've hidden all the hard stuff from the other programmers who need a standard boilerplate layout to start with or they would constantly be re-inventing the wheel so to speak.

I've looked at 100% WINAPI IDE'S like Firefly and find them still somewhat beyond my comfort level to really take full control of.

I'm not doing bad since I started by converting Dos (ugh) programs and kept their procedural mentality while inventing different message pumps to emulate the old inkey$ routines in the Dos screen routines I was inheriting. As time went on I would patch here and enhance there and occasionally write new programs the right way.

As the demand for more controls, COM interfacing, listviews, tab controls started being required, I knew a year ago I had to start working toward something more standardized with a great deal of the 'innards' hidden from view. Our programming style doesn't lend itself to the VB or VB.NET and would be very hard and expensive to convert to.

Powerbasic gives me a middle ground where we can have acceptable programs in the current style while moving our most used programs to a full blown Windows Style programming.

My plan is to use PB Forms purely for the GUI and separate the business logic so that our lesser skilled programmers can lay out the screen and modify them without bothering the business rules area.

I plan on creating a select number of SuperClassed and SubClassed controls that others can just add to their PB forms using the Add Custom control option. Just by adding the field, I plan on building in lookup function to other files, input masking, character by character restrictions etc.

Some listview will load the entire file at once while others will have an incremental lookup which will load in just what is needed. Still other huge files in listviews will load in just 20 records at a time and navigate under program control so that no matter how large the file, it will be instantaneous. Even changing the index that the listview works within this scenario is worked out in test programs.

I do know better now, thanks entirely to the PowerBasic Forum, individual responses and Poffs (which I'm finally starting to make sense of).

I hope also that some of my questions and postings will indirectly help others who are facing similar questions.

Bob Mechler

[Michael Mattias]

Ah, yes, I remember that now.

"We need to get this done today, so let's just get it done and we'll make the permanent version later."

Just last week a major US company (OK, it was Wellpoint, about $15B/year revenues. I think that qualifies as major, doesn't it? ) finally took out of production some 'temporary' programs I created for them... in 2003 and 2004.