|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Fri Aug 30, 2013 7:55 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Fri Aug 30, 2013 8:20 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
silicondale
Joined: 15 Mar 2007 Posts: 250 Location: Matlock, Derbyshire, UK
|
Posted: Fri Aug 30, 2013 9:51 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Sat Aug 31, 2013 6:44 am Post subject: |
|
|
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. |
|
Back to top |
|
|
silicondale
Joined: 15 Mar 2007 Posts: 250 Location: Matlock, Derbyshire, UK
|
Posted: Sat Aug 31, 2013 9:38 am Post subject: |
|
|
hi Paul - many thanks. Screenshot and code below. Still using fixed-format 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.
Code: |
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sat Aug 31, 2013 10:52 am Post subject: |
|
|
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 INTEGER*4 or REAL*8, then you don't get the round off!
Eddie |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sat Aug 31, 2013 11:42 am Post subject: |
|
|
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
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
Code: | 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
Last edited by LitusSaxonicum on Sun Sep 01, 2013 12:20 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Sat Aug 31, 2013 8:28 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
silicondale
Joined: 15 Mar 2007 Posts: 250 Location: Matlock, Derbyshire, UK
|
Posted: Sun Sep 01, 2013 10:05 am Post subject: |
|
|
Many thanks for that, Paul. Will try this tomorrow (out for a long walk today) and will post back the results!
-Steve |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
|
Back to top |
|
|
Smib
Joined: 26 Apr 2009 Posts: 22 Location: Melbourne
|
Posted: Mon Sep 02, 2013 2:40 am Post subject: |
|
|
This is what I do:
Code: |
.
.
.
.
c initial array set up
info(1)='|Depth (m)|Variable A (MPa)|Variable B (kPa)'
view=1
nptss=2000
k=0
do j=2,nptss
k=k+1
write(a(j,1),'(i3)')k
call trim@(a(j,1))
a(j,1)=' '
a(j,2)=' '
a(j,3)=' '
col1=a(j,1)
col2=a(j,2)
col3=a(j,3)
info(j)='|'
call append_string@(info(j),col1)
call append_string@(info(j),'|')
call append_string@(info(j),col2)
call append_string@(info(j),'|')
call append_string@(info(j),col3)
enddo
.
.
.
.
i=winio@('%^lv[edit_cells]&',
+ ixxx,iyyy,info,nptss,sel,view,call_back)
.
.
.
.
THEN I USE THE FOLLOWING CALL BACK
c------------------------------------------------------------------------
INTEGER FUNCTION call_back()
include <windows.ins>,nolist
integer row,col,i,nptss
character*80 info(2001)
character*80 column(5),a(2001,4)
character*10 ddepth(2000),vara(2000),varb(2000)
character*80 name
c----- transfer data through common block
common a,info,nptss,ddepth,vara,varb
name=clearwin_string@('CALLBACK_REASON')
call_back=2
row=clearwin_info@('ROW_NUMBER')
col=clearwin_info@('COLUMN_NUMBER')
if(name.eq.'END_EDIT')then
do j=1,3
column(j)=a(row+1,j)
enddo
column(col)=' '
name=clearwin_string@('EDITED_TEXT')
open(unit=4,status='unknown')
if(col.eq.1) then
write(4,*)name
rewind(4)
read(4,*,err=101)depth
write(column(col),'(f10.2)')depth
write(ddepth(row),'(f10.2)')depth
close(4)
else
if(col.eq.2)then
write(4,*)name
rewind(4)
read(4,*,err=101)aa
write(column(col),'(f10.2)')aa
write(vara(row),'(f10.2)')aa
close(4)
else
write(4,*)name
rewind(4)
read(4,*,err=101)bb
write(column(col),'(i5)')bb
write(varb(row),'(i5)')bb
close(4)
end if
end if
a(row+1,1)=column(1)
a(row+1,2)=column(2)
a(row+1,3)=column(3)
101 continue
info(row+1)=' '
do j=1,3
call append_string@(info(row+1),'|')
call append_string@(info(row+1),column(j))
enddo
call trim@(info(row+1))
call window_update@(info)
end if
150 continue
END
LATER IN THE PROGRAM I CONVERT FRON STRING TO NUMBER AS REQUIRED |
Cumbersome but ok for 3 or 4 columns of variables. I am sure someone can improve it
Brian |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Sep 02, 2013 11:55 am Post subject: |
|
|
Brian,
Some interesting points here, including the use of append_string@ instead of concatenation with //. Why do you read and write to a file instead of a character variable, needing a REWIND and a CLOSE, when an internal write would do ? The second WRITE could be replaced by an assignment, although speed is not of the essence here, and the code is very explicit. e.g.
Code: | read(name,*,err=101)depth
write(column(col),'(f10.2)')depth
ddepth(row)=column(col) |
You only check on 'END_EDIT', and as I understand it, reject the whole string for a cell if there is a formatting error in it. I think that Ian and I were looking to pick errors on the fly, thus minimising retyping, and also get a more Excel-like method for moving through the grid.
Eddie |
|
Back to top |
|
|
jalih
Joined: 30 Jul 2012 Posts: 196
|
Posted: Tue Sep 03, 2013 9:34 am Post subject: |
|
|
Just a thought...
Could the behaviour of the existing list-view control be modified by providing a %mg callback to handle the WM_NOTIFY message?
List-view control sends the LVN_BEGINLABELEDIT notification when label editing begins. If you have a handle to the list-view control, you can send LVM_GETEDITCONTROL message to it and retrieve a handle to the edit control working as a label editor. Now you can send some messages to it, or subclass it to provide input filtering and additional key handling for moving between items in a list-view. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Tue Sep 03, 2013 1:01 pm Post subject: |
|
|
"Callback reasons" are already provided for LVN_BEGINLABELEDIT etc. |
|
Back to top |
|
|
jalih
Joined: 30 Jul 2012 Posts: 196
|
Posted: Tue Sep 03, 2013 1:27 pm Post subject: Re: |
|
|
PaulLaidler wrote: | "Callback reasons" are already provided for LVN_BEGINLABELEDIT etc. |
Ah, that's true.
It should simplify things for us even more. We only need to get the handle to the edit control working as a label editor and subclass it. Now, it should only be a matter of writing a new window procedure for the subclassed edit control.
I am currently busy moving into a new home and have tons of things to do. I will try to post some working example as soon as I find some time for it. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|