I have looked up the style property and have got the code for

set_table_multiselect but can't seem to get it to work.

The table has 4 columns. Col 1 is hidden

1,2,3 are protected. 4 is edittable and

the More-]protected is on. (I don't want insert or delete enabled).

I would like to be able to allow the user to select multi rows

by dragging the mouse then click a button which will interrogate

the selected rows and perform some updating.

I think some ducks are out of line… help?

You realise that mouse drag is not directly exposed by PS - however the edittable does allow this functionality. The following code works for us :-

winStyle=.table_1-] style

winStyle=iconv( winStyle3,\00\, "MX" )

winStyle=bitOr( winStyle, 512 )

.table_1-]style=winStyle

The Sprezzatura Group

World Leaders in all things RevSoft

I have had it working previously, but you have to drag the row markers on the left to select the rows.

I will see if I can find my code and advise.

Colin

Still no go. I tried the sprezz code also.

Are there and caveats (is that 's or s') ?

I have this code in the create event of the window.

Now no highlighting of rows is happening.

Is there example code in the sysproc MSG ? Line#'s ?

Thanks for the responses.

BC

After some digging and a call (thanks BC); I hadn't

realized you needed to get the structure, destroy and recreate.

Well I've got it working with the row buttons.

I would like it to function within the table however.

At least I can move on… Thanks

Ermm this just works for us regardless of where we put it without a create and destroy, we can even put it on a button and change default behaviour on the fly.

Something is rotten in the state of Denmark.

The Sprezzatura Group

World Leaders in all things RevSoft

Hmmm or rather ermmm is right… I tried your code and 'nuttin'… I would rather

use it, it's clean and simple.

Also mine only works with row buttons and I don't have source for MSG_SUB to see what the differences may be.

Bruce,

I had a problem once where I couldn't get multi-select to work the way I wanted. I had to hold down the Shift key while selecting, and I didn't want that. I recall trying with single clicks, but don't remember if I tried dragging.

It could be a different problem from yours, of course. But try the Shift key and see if you get a different result.

To get rid of the problem I had to use System editor and edit the column styles in the form's SYSREPOSWINS or SYSREPOSWINEXES row. See . I'll see if I can dig out the details.

- Oystein -

Bruce,

This thread tells more about my multi-select problem: .

The problem disappeared when I made sure the 4=editable style was set. But as I said before I had to do this by editing the SYSREPOSWINS or SYSREPOSWINEXES row with System Editor.

Tell me if you want more explanation.

- Oystein -

I would like more… here is what I am doing now in the create event.

I'm not sure if I have to add more or not. It works with pushing the buttons but now you can't hilight a row without pushing the button.

ostruct=Get_Property(ControlId, "ORIG_STRUCT")

Call Utility("DESTROY",ControlId)

Style=ostruct

if Style 1,2 _eqc "0x" then

 convert @lower.case to @upper.case in Style

end

Style=iconv(Style 3,99, "MX")

Style=bitor(Style, 512)

ostruct=Style

Call Utility("CREATE",ostruct)

Bruce

Bruce,

I don't destroy and recreate. I don't know if it matters.

Take System Editor and open your form's SYSREPOSWINS row. Find the entry for your edit table.

Here's the entry for a 3 column multi-select edit table of mine. (The edit table's name is "LIST", the form's name is "LISTE_CHILD".) I have highlighted the style settings:

LIST

EDITTABLE LISTE_CHILD 30 10 714 309

0x508021c0 0x0 2

0 MS Sans Serif

-11

700

0

0

0

0

34

0

1

2

1

0

0

R

EXECUTE

REGIMUS*STPROCEXE@WINDOW GOTFOCUSú@SELFú@PARAM1 R EXECUTE REGIMUS*STPROCEXE@WINDOW

POSCHANGEDú@SELFú@PARAM1ú@PARAM2

GOTFOCUS POSCHANGED

0 0

]

]

] ]

]

] ]

]

] 0

0

0 0x0 0x0

10

20

200 3 0 261 261 261 40

50

120

500 Nr

xxx

Text

What have you got in your edit table's style settings?

If by chance any of them are 257, try and change them to 261. Then save and close the row, and recompile the form with Form Designer.

BUT DO IT ON A COPY OF THE FORM, NOT THE ORIGINAL. Or is that enough? Better do it in a copy of your system.

- Oystein -

PS. It's bedtime around these parts now, but I'll check the list tomorrow.

Bruce,

Latest idea: When in your CREATE handler you destroy and recreate the edit table you get its original structure, change a part of the structure (to be more precise you set the "512-bit" of the style), and use the changed structure for the new version of the edit table. If your problem really is the same as mine, perhaps it can be solved by changing other parts of the structure at the same time - the column styles, wherever in the structure they might be. My theory is it helps if the column styles have their "4-bit" set.

- Oystein -

Bruce,

(1)

Please tell me: Do we have the same problem or not?

My problem is not getting an edit table to become multi-select. I don't think I ever had any problems with that. My problem is with the way one has to click or drag when one wants to select multiple rows. Very often in a multi-select edit table one has to either use the row buttons, or, if one wants to click or drag in the cells, hold down the Shift button while one does it. I want to do multiple selects with plain (un-shifted) clicking/dragging in the cells. Because using the Shift button is awkward and unnatural. And because my edit tables often have no row buttons.

Is this your problem too?

(2)

Once I had this problem I managed to get rid of it by doctoring the column styles in the SYSREPOSWINS or SYSREPOSWINEXES row of the form, like I described in my postings yesterday. But I was never happy with the solution, so when your postings reminded me of the problem I decided to look at it again. Yesterday I was certain the problem had to do with one particular bit in the column styles. My earlier extensive experiments told me so. Today I've looked at more examples and my theory seems to crunble.

Damn!

- Oystein -

Oystein,

Yes, it works if the user clicks the row buttons, holds down and drags

down the row buttons.

The thing is that the row that has focus is not lit but when returning the selected items it will be included.

I guess I don't fully understand the style property values from the doc. Do I have to set more than one value? Do I have to do each column? How is this laid out?

Thanks for all your responses.

Bruce

Bruce,

Yes, it works if the user clicks the row buttons, holds down and drags down the row buttons.

The thing is that the row that has focus is not lit but when returning the selected items it will be included.

When you say "the row that has focus" I assume you mean the one containing the current cell - the one which has got a dotted line around it.

While the selected rows, on the other hand, are blue, with depressed buttons.

The current cell (focus) may or may not be in one of the selected lines.

The SELPOS property of the edit table should only include the selected lines. But you say that even when focus is in a line not selected, the focus line is also included in the selection, i.e, is included in the SELPOS property of the edit table?

I have two or three multi-select edit tables that I actually use in an app, but I've never seen that problem.

What exactly are your settings for the edit table (the ones you do in Form Designer)?

I guess I don't fully understand the style property values from the doc. Do I have to set more than one value? Do I have to do each column?

That was my theory for the solution of my own problem, a theory I've laid to rest. That I could change some other style bits - the ones for each edit table column - to avoid having to Shift-click or click the buttons instead of the cells.

How is this laid out?

I guess you can glimpse the layout from the edit table's entry in the SYSREPOSWINEXES row. If you really need to know Sprezzatura sell some documentation. (Which I haven't got.)

- Oystein -

View this thread on the forum...