Changing the size of the colums in a browse is not persistent, is it desired?

[georgefurnel]

Good day,
I have noticed that changing the size of the column width (resizing) of an embedded browse, during runtime, is not persistent. Ie once you reopen the application the size is the way it was before I resized it.

Is there a way to let this change be persistent?

Kind regards
George

[Tom Cone Jr]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

Sure. Change the column width while form is in design mode and save the form.

[georgefurnel]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

:) :)

Tom, my users each have different needs (and screen resolutions) and hence they want to change the column size to fit their own individual needs.

Thus, I need a way to 'keep' the size for that user on his pc, and programmatically reapply the comumn width when the users opens the form.

Is there a way to do this?

Regards
George

[Tom Cone Jr]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

George, I haven't tried to do that myself. Suggest you search for related threads across the entire message board. (including the code archive forum)

The embedded browse object includes properties settings for each column. I can imagine a script that saves the column widths to disk, and then another one that reads them back and applies them when the form next opens again. If you find this has already been written, or if you write it yourself, please let us know.

And... you might want to post a request that browse column widths be "sticky" in the Features Wishlist forum.

-- tom

[Tim Kiebert]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

Sounded like an interesting exercise so I haven't checked the forum for any existing code but had a crack at it myself. Wasn't too hard in the end. This is bare bones, no error checking or the like. Just a proof of concept really. If you had a browse with a large number of columns you may need to use a memo field instead of the character that I used. Of course you wouldn't even need to store the sizes in a table. They could be written to a text file. In fact writing to a text file on the local machine would probably make it more user specific.

[Tom Cone Jr]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

Tim, this might be a good spot to use Registry.save_settings() and Registry.load_settings() in order to store and retrieve the column dimensions. -- tom

[Tim Kiebert]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

Tom, Oh great, I wish you hadn't 've said that. Now I am going to have to investigate that aren't I. Whether I do that now(12:30 am) depends on the affect this last glass of port is going to inflict on me. Either make me sleepy and go to bed or destroy my judgement and stay up even later.

[georgefurnel]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

Are you 2 having fun? :)

[Tim Kiebert]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

Yep, hic!!

[csda1]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

Hi Tom & Tim,

It's probably a real bad idea to save the values in a registry for these reasons;

• May have Vista incompatibilities
• May be stopped by some anti-virus software
• Registry is cluttered up with too much windows junk
• Not easy to move settings to new location if needed

It is best, IMHO, to store settings as a text file or database entry in a special table. In general, there are levels of directories (or hierachy of the data) that I use.

• Shared directory of all A5 users (of your own creation)
• Database directory (and sometimes the shadow directory)
• local system directory (shared by all users)
• local user directory (for only 1 user) - In alpha 5 this is the exe directory for version 7 and less, and the application directory for version 8 and up
• Private directory (temporary usage - may be erased)

Depending upon who you want to be able to share the information, controls where you put it. (or allow one level's existence to override another's in a intelligent priority order)

Tom, this is an example of where you might put the "multi-function" function concept I talked about at the Alpha Five 2007 conference to use. A function would have options (read as parameters) to

• initialize all of the browse column widths upon init event of the browse and set up an exit browse event(or append to the current exit browse event) to save the values upon exit (which would be basically a call to the routine with a different parameter that runs the desired exit code and then runs the current exit event code)
• process the exit event

Thus your code to both save/restore and setup exit events is all contained in a single function (making the related code easier to maintain consistency and easier for use). So the init event might have

BrowseColumnSaveRestore()

and the exit event code which is modified on the fly by the init event (and thus is not physically there) would look like

BrowseColumnSaveRestore("X")
....Old Exit event code here....

George - Don't worry about this unless you want to - It's just overkill for Tom and Tim about techniques.

These are the same basic techniques I use in the CSDA Code Utility for function design and saving settings and have worked reliably.

[georgefurnel]

Re: Changing the size of the colums in a browse is not persistent, is it desired?

No Ira, on the contrarily, I find this most interesting and thought provoking.
Thanks for your input.

Regards
George