forums.silverfrost.com

[PaulLaidler]

Looks like the code you posted is not complete.

[IanLambley]

Here is the complete code for the callback, main program remains the same. Note, I used an array to store the list of callbacks as using a print within the callback produced the error regarding printing whilst already printing.

[PaulLaidler]

I have taken your sample as a starting point and created a listbox control that a) rejects numerical input and b) converts lower case alpha characters to upper case. In the process it has become apparent that %lv is not fully documented even in the enhancements file. I am hoping that the new sample will help to show what can be done. I have not aimed to be clever when merging the strings. There will be a better way to do it.

[PaulLaidler]

I have had another go at this and I have simplified and improved the code

[IanLambley]

Thanks Paul, take the rest of the evening off!

I notice that when one uses the cursor keys to move right or left, and the contents of the current cell are highlighted, it moves to the next or previous cells and they become highlighted. When in the last column, the right cursor unhighlights to contents and allows in-cell editing. To unhighlight the contents of any cell, for in-cell edits, the Home and End keys move to edit mode at the start or end of the cell. If the tab key is pressed, the highlighted region is lost and the mouse has to be used to select anything. Is this intentional?

Regards

Ian

[PaulLaidler]

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.

[IanLambley]

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

[LitusSaxonicum]

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.

[PaulLaidler]

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.

[LitusSaxonicum]

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

[IanLambley]

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

[LitusSaxonicum]

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

[silicondale]

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

[LitusSaxonicum]

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

[silicondale]

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