FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

TEXT

Manage large grid cells


Further to your original question, I've just done a quick test using the "Base Program". This works :

1. Trap a Mouse click in the main window, and draw an edit field centred on the Mouse Click. (One line of code)

2. Use the Edit Field as normal.

3. On an _EFReturn event, extract the text in the Edit Field, and close the Edit Field. (One line of code) Do whatever you want with the extracted text.

4. Copy the gWorld to the screen in the area bounded by the edit field rectangle (closing the edit field doesn't generate an update event, for some reason) (one line of code)

You now have the ability to generate dynamic edit fields that open and close in the main window without having to muck about with doing them off-screen. In the same way, you could trap tab events and do the same thing, etc. You could even scroll the main gWorld from a Tab Event. And finally, you can edit a spreadsheet in the spreadsheet itself, rather than at the top. Good, Eh ?

.Phil

recent discussion (GWorld newbies) reminded me of a post of my own from a little back... namely, you never need to do more than one edit field in any one window. Especially if you're doing a cell like structure. You just need to know precisely at any one point where in your window you are, so i use a record to keep the info.

Imagine an XL style page with 489 lines and 524 columns. You need a basic record giving the height and width of these beasties (record 1). You need to keep the info somewhere that should be appearing in the cells (left up to programmer :-). You then need to have a record that contains the H and V offset into your seerhing mass of cells (record 2), and know where is the active cell.

Suppose 1: - handling clicks
User clicks on a cell. using the info in records 1 and 2 you can quickly find out which cell is clicked. Then you build on the fly an edit field at this point, keep the handle, dims etc. in Record 2. Jump into your structure to get the info for that cell. Put this in the record field. When the user clicks out of the field, grab the info, put it back in your structure. Kill the EF - and clean out the info in the record - generate an invalrect for the screen estate where the rect was.

Suppose 2 - updating
Using info in records 1 and 2 you can quickly find out the cell in the top left. Then in your offscreen GWorld, build up a picture of the page using the info in the structure. grab the refresh region, copybits in the refresh.

Suppose 3 -scrolling
get the horizontal and vertical offsets. Pass them on to record 2. recalculate the new starting point. generate an invalrect for the window. Go to the Supposition 2. (scrolling doesn't have to be through the scrollbars, you can give the user a 'hand' tool to push the cells around - just capture the start cords, the finish coords, grab the difference and pass that to record 2 (ut in this case, don't forget to update the scrollbars too)).

You can even have 2 structures for your data. One containing the data, and the other containing the style info for that data.

I have used this technique to give very fast scrolling through fields of cells with no problems.

.Jonathan