%lv edit_cells

I cannot remember how much of this was planned. It might have been better if the arrow keys caused the cell selection to wrap on to the next row etc. What happens in Excel? The tab key behaviour is irratic but I guess we can live with this. The alternative may be for me to change the code in order to simply disable the tab key whilst %lv is active.

Paul,

Thanks for looking at it.

Excel does the following when the keyboard is used:

Cursor keys move to the desired cell but do not highlight the text.

F2 enters edit mode and positions the cursor after the last character, no highlighting.

Tab moves to the next cell to the right.

Shift-tab moves to the next cell to the left

Home key moves to the leftmost cell.

End key confused me, but it seems that it acts as a 'second-function' key on a calculator. If you press 'End' followed by a cursor key, it moves in the direction of the cursor to either the first or last populated cell or the extremes of the worksheet The same can be achieved by holding down the control key and pressing the cursor keys.

When the data in a cell is selected, then the cursor key removes the selection, unless shift is pressed then it can extend or reduce the selection.

So it appears that for %lv, End acts as F2 and then the horizontal cursor keys act within the text of the cell, and there are few other similarities.

I think that the tab/shift-tab operation is a real miss. It would also be useful to implement the control+cursor-key method of moving around. Perhaps control+tab should exit from the control to the next control if any, and shift+control_tab, to the previous.

Perhaps a vote from interested parties would be good.

Regards

Ian

So this thread stopped some years ago. Did work on it also stop? Paul's (improved) code doesn't work very well in Windows 7 with 1 24 default.manifest, but does when this line is absent (using v6.10). The enhancements file for 6.20 doesn't suggest that has been fixed. (Oddly, code of mine that wouldn't work yesterday at the end of the day worked fine after a clean reboot, but after several goes, wouldn't work at all, suggesting that it is a Windows issue. I managed to introduce the same problem into Paul's example by adding a resources section and incanting the mantra '1 24 default.manifest').

I'm trying to teach myself some of the Clearwin controls I have avoided - %lv being one of them (I 'retired, hurt' from an encounter with %bv and %tv some years ago, and %lv seemed to me to be likely to be the same, but worse). Matters are not improved by the typo errors in the FTN95.CHM section on %lv. The CHM file contains all the notes in the ENH file that are relevant, so no further help there.

I'm sure that someone out there must have a working callback for making sure that cells contain an editable floating point number, and I wonder if anyone would care to post such a routine, please? I'm getting tied in knots working out when to reject a decimal point marker (for instance) because there's already one there, and suchlike. My application needs to be able to edit in place a grid of 26 rows, where after the heading there are 25 rows each starting with a letter of the alphabet followed by 3 coordinates x, y and z, the coordinates editable in place. Doing it with rows of %rs + 3x%rf is easy, but looks clumsy.

Is it just me who finds the multiple coordinate systems in %lv maddening? And also my inability to position the 'cursor' on a particular cell, particularly one I have decided contains an error that I cannot fix without use intervention.

It has become obvious to me why early Windows spreadsheets didn't allow editing in the main grid, but only in a separate box. However, the very appearance of the grid in a listview control entices the user into the belief that the cells are editable in place.

If I have to interpret the entries key by key, then perhaps it is time to bite the bullet and program such grids into a %gr region.

Sorry but I don't have the time to work on this at the moment. A new release is about to go out. However, %lv has not changed recently.

Paul,

May I then suggest that investigating %lv goes on the 'to do' list for a future release? It is far from a priority for me, as I'm only experimenting, and the fact that the XP manifest affects it is pretty much of a show stopper for me even beginning to contemplate using it in earnest. However, my reading of the forum suggests that some commercial software developers use it a lot ...

Eddie

Eddie, It seems that my suggestion of a vote fell on stoney ground, and therefore Paul placed a very low level of importance on any development. Of course, that results in nobody attempting to use it and it remaining unpopular. I would love it to work better.
Perhaps the development team is not big enough and from looking at the other posts for enhancements to catch up with other syntaxes of Fortran etc., it seems that there is no spare development resource. If that persists and FTN95 is no longer at the forefront as it used to be then the maintenance paying customers will desert in droves and the income will evaporate as will the development team, leaving us high and dry with impossible re-development tasks to achieve on other compilers. Regards Ian

Hi Ian,

I’m not sure about your diagnosis or your prognosis, but I am sure that in this case the problem lies in the Clearwin wrapper for %lv, as listviews work in Windows 7 with the XP manifest, and %lv doesn’t – at least not ver 6.10 (which should – see below!). The fact that the thread lay dormant for so long does suggest that there isn’t much interest in %lv, which is a pity, because I could see a lot of use for it. Sometimes there is no easy substitute for just typing numbers into a table like you can do so easily in Excel.

I spent about 3 or 4 hours today coding a %gr-based equivalent to the %lv view=3 grid, and have got as far as I did struggling for 2 days with %lv. The big difference is that %gr works, and %lv doesn’t, and what was stymieing me with the latter was not understanding that it wasn’t my fault.

I get great use out of Clearwin.enh. I also look at the bug fix list (Revision History page). For example, I spent ages trying to get popup menus to work in a %gr region with full_mouse_input, but I was using 4.90, and the Revision History page shows this feature as available from 5.50. I would like an equivalent list or page telling me what doesn’t work, so that I wouldn’t need to waste time with a “bright idea”. There are 4 fixes for %lv listed: 5.40, 6.00, 6.10 and 6.20 (so clearly work has been ongoing in this area). The fix reported for 6.10 is the problem that I’m still having even though I am using 6.10. Sometimes I download the PE so that I have the latest version, to see if something I’m struggling with has been fixed.

Eddie

This one seems to have gone quiet again. Now I'm coming in as another user with a quasi-spreadsheet editing requirement.

I haven't tried %lv and from reading the documentation and the forum I'm not sure if I want to.

It may be easier just to use a grid of %ob boxes each with %rd %rf and %rs controls as appropriate. Low-tech but it does seem to me easier and possibly more reliable. Can I ask if Eddie or Ian has succeeded with %lv - or perhaps found some other workaround?

-Steve

Steve,

It all depends what you want. If you want the full facilities of Excel just by using the %lv control, then you will be disappointed.

I have tried arrays of %rf or %rd boxes, and achieved a working solution, but it is VERY ugly.

In May last year (see dates on posts) I gave up on %lv and programmed a solution where my grid (and its contents) was displayed in a %gr area, and any row (or cell) can be selected with the mouse. This loads the row contents into a set of %rf edit boxes ... I haven't yet got round to putting the cursor in the right %rf box ... and various accelerator / shortcut keys like Home (goto top row) and End (goto last row) together with cursor keys do work, plus the ability to inset and delete rows, etc. This represents the sort of out-of-grid editing you got with VERY early Windows (and DOS) spreadsheets. Advantages of this approach: you get any appearance you want. Disadvantages: no in-grid editing. You are welcome to the code, but it will need to come via Dropbox.

By way of contrast, %lv already does in-grid editing, but my May 17, 2012 3:48 post contains the nub of the problem. %lv works in terms of strings. If you are working in terms of strings, then in principle, anything entered at the keyboard is 'valid'. If you want an integer, the tests are simple: allow only digits, and reject overflow, also permit + or - keys (but only in the first non-blank position). However, when editing a floating point number, there are lots of things that would prevent you translating the string into a floating point number. For example, you might reject a decimal point if there is already one in the field, but that prevents a user adding one where it is really required and then deleting the other. (All this stuff is done in an %rf box!).

I have spent some time exploring in-grid editing for floating point numbers both in %lv and in my home-grown solution, and my home-grown solution requires at least as much effort and the same type of programming, so my status at the moment is: 'given up (for the time being) on both'.

I find this all frustrating, because sometimes simply typing numbers into a grid is the obvious and simplest way of getting the data into a program.

Eddie

Hi, Eddie - I feared as much. The purpose of this edit grid is for editing data tables which will contain columns of strings and columns of double-precision numbers. The number and positions of columns of each type is determined only at run-time as the tables come from users' data files. No integers, only floating-point, so it seems that %lv is a non-starter. For now I shall persevere with the %n.mob / %rf %rs solution despite its ugliness because at least the functionality is what I need. Many thanks for your kind offer, but I think the %gr option might also lead into a quagmire that I don't want to drown in!

It pains me to say this, but I think I may need to look for other (i.e. non-CW+) ways around the problem, like bringing in third-party code - I seem to recall that there were some callable mini-spreadsheet systems. If I can call one of these from Fortran, to run in its own window and return the arrays to the calling program, that might be another answer.

-Steve

I think that it would be relatively easy for me to provide ClearWin+ filter for the %lv edit cells so that they only accept say real numbers or integers.

It would be simpler if one filter was to be applied to all cells (other than the first column which I guess would always contain fixed text). The selection of a filter could then appear as a %lv option. To allow the filter to vary from one cell to another would be do-able but a little more tricky.

I am thinking that the cell data would still be received as text and ClearWin+ would only do the filtering of characters that the programmer would otherwise do in their own callback. The programmer would then do an internal WRITE to translate to numeric form. This would kept the design flexible and open-ended.

If this would be of interest I could put it high on the list of priorities.

Paul,

Sometimes simply typing numbers into a grid is the obvious and simplest way of getting the data into a program.

At present, %lv is great for displaying things. Although it has in-cell editing, the problem is that it is difficult to guarantee that the edited string contains either a valid integer, or worse, a valid floating point number. I agree that it would be difficult to make individual cells TYPE specific. However, if you are game, then making individual columns type-specific would seem to be a step forwards, perhaps by specifying a mask for the columns somewhere into Character, Integer or Real.

Eddie

I've now had a chance to implement and test the %n.mob and %rf/%rs coding, and it works fine. It isn't even especially ugly. Using a simple default border on the %ob grid, and suppressing the borders on the %rs and %rf using %co[no_data_border]. It looks clean. The only problem is that the %ob grid leaves a bit too much white space margin around the input cells. Is there any way to reduce the width of this margin? What I like about this is that I have complete freedom to program whichever type of input I want in each box, so I can mix and match columns of number boxes with columns of text boxes, a row of header boxes across the top, and row numbers down the side. (Almost) happy! Not even trying to do coloured backgrounds yet - I imagine this might be tricky - but with everything on a white background, I'm free to use colour, bold, italic, and different fonts for the data elements. Looks quite good with header row and row numbers column in bold, all else in normal font.

I don't think there is currently an easy way to reduce the margin width. If you can post a short sample program, I will see if it can be done internally.

hi Paul - many thanks. Screenshot and code below. Still using fixed-format 😮ops: as you can see! I've removed the callbacks on the data items but this doesn't affect their appearance of course.

By the way, just noticed. The firstnumber 12345.6 is displayed as 12345.59. Since this is a double precision number I am surprised at such a rounding error! Is the internal coding done in single precision, perhaps? The second number also comes out wrong in its last decimal place.

      subroutine test_v
      use mswin
      integer*4 nrow(2)
      character*8 a(2)
      double precision d(2)
      integer*4 donetest
      external donetest

      a(1)='ALBERT  '
      a(2)='VICTORIA'
      d(1)=12345.6
      d(2)=9876.543
      kk = winio@ ('%ca[Spreadsheet?]&')
      kk = winio@ ('%co[no_data_border,check_on_focus_loss]&')
      kk = winio@ ('%3.3ob&')
C HEADERS
        kk=winio@ ('%cb&')
        kk=winio@ ('%bf%8rs%`bf%cb&','Names')
        kk=winio@ ('%bf%8rs%`bf%cb&','Numbers')
C DATA ROWS
      do j=1,2
        nrow(j)=j
        kk=winio@ ('%bf%4rd%`bf%cb&',nrow(j))
        kk=winio@ ('%8rs%cb&',a(j))
        kk=winio@ ('%8rf%cb&',d(j))
      end do
      kk=winio@('%ff%^bt[OK]',donetest)
      return
      end
      integer*4 function donetest ()
      donetest=0
      end

-Steve

Hi Steve,

Great result - I used arrays of input boxes, and that is ugly - I didn't think of using no_data_border and the lines from a nest of %ob-%cb, and when you said that, I thought they were all going to be [invisible].

Your constants ARE single precision. If you add a 'd0' to the end (or the appropriate KIND business), or use OPTIONS(INTL,DREAL) which makes all the constants as well as non-declared variables with IMPLICIT type into INTEGER4 or REAL8, then you don't get the round off!

Eddie

If you us %`rs on the column headers, they won't be editable.

I've just had a further thought. Although you can run through the data boxes forwards with TAB and backwards with Shift-TAB, you can't jump from row to row.

If you use %lc on every editable data box to build up an array of handles, then in your callback for each editable databox you can use

iHWnd = GetFocus()

to find the handle of the box you are in. A quick scan through the handles will give you current row and column numbers to save somewhere (COMMON block?).

Then, you could declare accelerator keys using %ac to do the row-jumping function. Perhaps you could use Home to go to (1,1) and End to go to (n,m), with PageUp or cursor-up to go to the previous row - just look up the relevant handle and use

call SetFocus (iHWnd)

As well as %ac, you can use ADD_ACCELERATOR@ and REMOVE_ACCELERATOR@ subroutines in the callbacks for %sc and %cc. For 2x3 data arrays this is probably overkill.

Eddie

I have managed to reduce the margin to about half of its previous value.

The option to use is %ob[thin_margin] with the new beta uploaded today.

www.silverfrost.com/beta/salflibc.exe

Many thanks for that, Paul. Will try this tomorrow (out for a long walk today) and will post back the results! -Steve

Using the cursor to move up and down was described in the following post: https://forums.silverfrost.com/Forum/Topic/1246&highlight= Ian