BR Forum

Susan,

I don't know why Curfld isn't working for Radio buttons. That sounds like it might be a bug to me.

However, I don't see why you can't just loop through ALL your controls and validate them all, no matter which field the user modified? Does it take too much time to validate your controls?

What I usually do is:

1) I read the record on the disk
Read #DataFile, using form$(Datafile) : mat f$, mat f

2) I transfer the information from the "Record on Disk" to the "Record on Screen"

let s_data$(1)=f$(cu_name)
let s_data$(2)=f$(cu_description)
let s_data$(3)="Male"
let s_data$(4)="Female"
if f$(cu_gender)="M" then
let s_data$(3)="^"&s_data$(3)
else
let s_data$(4)="^"&s_data$(4)
end if

3) I input from the screen.

rinput #window, using mat s_spec$ : mat s_data$

4) after inputting I validate all controls

5) when the input loop is done, I copy all information back to Record on Disk arrays:

let F$(cu_name)=s_data$(1)
let F$(cu_description)=s_data$(2)
if s_data$(3)(1:1)="^" then
let f$(cu_gender)="M"
else
let f$(cu_gender)="F"
end if

6) Finally, if the user wanted to save the data, I save it:

if ExitMode=SaveAndQuit then
rewrite #DataFile, using form$(DataFile) : mat f$, mat f



Of course, this is a simplified example. I actually have routines that do each of these steps in a more generic manageable way. Also, with ScreenIO, I'm not sure when one of your custom functions wants access to the current state of the Record on Disk (mat f$, mat f), so I validate and save all data in the Rinput Fields statement in one step, Each and Every time the rinput fields statement is done. It doesn't waste time when I do it, the validation and saving generally goes so fast it looks instant.

So with ScreenIO, the steps are:

1) Read the Screen Definition (this tells which record on disk goes in which place on the screen)
2) Read the record from the data file
3) Build the input specs (build mat s_spec$)
4) Do
5) Copy data from Record on Disk to Record on Screen. (build mat s_data$)
6) Preform the Input statement
7) Validate the data and save it from Record on Screen back into Record on Disk
Check how the input ended and process accordingly (did they click on a button, or press escape, or what)
9) Loop until Exitmode
10) Save the Data back to the disk with a Rewrite statement (or a regular "write" if we are adding a record).

ExitMode is set to non-zero either by pressing the ESC key or by clicking on a button that sets ExitMode. (step 8 is when it actually gets set)


It looks like George answered the majority of your questions.

Yes, to tell which thing was clicked on, just check for the presence of "^". To set which thing is selected initially, simply put an "^" in the one that needs to be selected.

This way you can fairly easily save the presence of the "^" or not into your data file using whatever logic you want to use.

In ScreenIO check boxes have a setting that says, "What goes in the datafile if its Checked? What goes in the data file if its Not Checked?". We'll probably make radio buttons work the same way when we add them.


However, Georges answers sparked some (incidental) questions of my own:

1) George, you mention that Search is Case Insensitive if your search item begins with a "^"?? When did that start working? Is it 4.2 only? I never knew about that, thank you for letting me know. I'm sure its faster, and its certianly cleaner code, to use "SRCH" then it is to use a For Next loop, but I have been using For Next loops any time I needed to do a case insensitive search because I didn't know SRCH could handle a case insensitive search.

2) Your examples showed exiting a FOR NEXT loop by using a GOTO statement. Does that properly close out the FOR NEXT loop? I always figured that would leave the FOR NEXT loop sitting on the FOR stack or something. I have been setting the INDEX to the MAX VALUE when I wanted to exit a for next loop (until Gordon would implement an EXIT FOR statement in BR) in order to properly exit out of the FOR loop.

It looks like the number 8 followed by a paren makes a face in the forum...

Gab:

The "^" case insensitve search started in 4.2. It is a good idea, however it also creates some potential problems. For example, the FNPFKEYLINE function and then my FNWINBUTTONS functions which was modeled on it use the "^" character to mark the start of a button definition. The Function searches for the "^" and set the button based on its position. 4.2 causes this function to fail without some modification

The character that designates the case insensitive search can be changed or disabled with a config statement. If you look at FNWINBUTTONS in FNSNAP.dll you will see that I check to see if "^" is configured for case insensitve searching. If it is I disabled it at the beginning of the function and then reenable it at the end of the function.

43714 IF POS("^","^")<1 THEN !: LET CHAROFF=1 !: EXECUTE "config SEARCH_CHAR OFF" ELSE !: LET CHAROFF=0

43975 IF CHAROFF THEN EXECUTE "CONFIG SEARCH_CHAR 5E" : LET CHAROFF=0

Gab:

2. Yes, my example was quick and dirty. It would have been better to use a DO LOOP rather than exit the FOR NEXT loop and leave the stack potentailly dirty.

I've been traveling and only had shart access to internet. Been to a friend's 50th wedding anniversary in Ohio. On the way back now.

Susan:

Try the attached modifide version.

With respect to CURFLD in conjunction with radio buttons, the following program is instructive:

00010 print NEWPAGE
00030 dim TEMP$(2)*8,SEX$(2)*8,MISC1$*20,MISC2$*20
00040 let TEMP$(1)="^Hot" : let TEMP$(2)="Cold"
00050 let SEX$(1)="Male" : let SEX$(2)="^Female"
00060 !
00070 Looptop: rinput fields "7,10,c 20,sae;10,10,radio 8,1,21;11,10,radio 8,1,22;10,25,radio 8,2,10;11,25,radio 8,2,11;13,10,c 20,sae": MISC1$,MAT TEMP$,MAT SEX$,MISC2$
00075 print fields "17,9,C 6;17,16,N 2;17,24,C 6;17,29,N 2": "CURFLD",CURFLD,"FKEY",FKEY
00080 if FKEY=99 then goto Endprgm
00090 goto Looptop
00180 !
00190 Endprgm: !

This, obviously is a rendition of Susan's test program. It points out that CURFLD is not changed when a radio button is clicked. Wherever the cursor is at the time the button is clicked is what is returned by CURFLD even when control is returned by an FKEY.

This can be useful. You may want to know where the cursor was when a radio button was clicked. Simply check your FKEY values before checking CURFLD.

However, this also points out some deficiencies relating to:

1) Displaying which radio button is currently in focus.
2) Being able to select a radio button via the space bar.

I will address these with Dan.


Notes:
Susan- The tab key seems to work the same with or without the T attributes because you have emulated the default behavior.

Gabriel- Nothing is left on the flow stack when you GOTO out of a FOR NEXT or DO loop, unlike GOSUB and FN routines which must be properly exited.

I did notice one very strange thing.


Susan had

...;10,10,radio 8,1T,21;...

This changed the "Tab Behavior" to work the way you would expect (Tab worked).

I would have expected

...;10,10,radio 8,1,T,21;...

Doesn't the "T" attibute go in the attribute field?

Luis-

New Console.doc and the wiki state-

Specify "row, col, RADIO cols, [group] [,Fkey] [,NOWAIT]": "[^]caption"

I doubt that the T had any effect.

Surprisingly, it did have an effect.
Without the "T", the tab did not stop at the radio buttons.

Good morning! I tried the "T" attribute combined with the group code because the Radio Button page of the wiki says:

[group] is the number of the radio button group. Any Screen Attribute would also be here after the group number. For example:

81250 Insert_Lines=1
81260 Insert_Above$="Above"
81270 Insert_Below$="Below"
81280 if Insert_Below=1 then Insert_Below$="^"&Insert_Below$ else Insert_Above$="^"&Insert_Above$
81290 RInput #Win,Fields "2,25,Nz 3,[D];3,25,Radio 8,1[D],-1;4,25,Radio 8,1[D],-1": Insert_Lines,Insert_Above$,

In this example, the [D] attribute is next to the group code with no comma separating them. Of course, I don't know what the [D] attribute substitution contains in this instance, but it DOES seem to me that there is no comma AND that screen attributes are allowed. And as Luis mentioned, the "T" DOES definitely work. It just doesn't give VISUAL focus to the radio buttons (which Gordon suggested is probably a bug).

-- Susan

George,

I tried your example and though I DID get better results, they still were not what I expected. Your example had the two sets (of two each) radio buttons followed by a text field. I get different results when I click on radio buttons than when I tab through them. And I can't seem to figure out the pattern. At first, when I clicked on the 1st radio button, curfld=4. But when I click on the 2nd,3rd and 4th, CURFLD is 1,2,3 respectively. So we were closer, though I'm not sure why. Is it the "X" attribute that you added to the radio buttons? But then I tried navigating through the fields with tab and the curfld values changed in a different way. I confess that I'm not that familiar with the "X" attribute and I'll go look that up. I use the "T" attribute regularly in my RINPUT statement processing to handle my entry loops.

Perhaps Gordon is right and this just needs some looking at from Dan. The way that I would EXPECT it to act, based on other windows programs, is to be able to tab through the buttons with focusing visually changing. And if I either click on a button OR press space bar while it has focus, then I would expect CURFLD to fire. I assume that there should be ONE curfld value for the entire radio button GROUP, but programmatically, you can still get around that if there were one for each separate element/button.

-- Susan

Gabriel,

The reason that I use CURFLD in my data entry loops to determine which field to validate is that I have some screens with 60-70 fields on them in the same loop. I wouldn't want to go through all of those validations, many of which read from auxiliary data files and display additional data on the screen. We're not just talking about things like checking for valid dates or if A=1 or 2, etc.

When my loan system is handing data entry (issuing a loan to a customer), a single field validation might include reading from 3-4 other data files to determine loan eligibility (and displaying a message box with the list of reasons they may have been turned down) and then if eligible, it could read several MORE files to determine the appropriate credit limit for that user and display the results. I definitely wouldn't want to be doing that on every pass through a large loop. So I isolate my validations for each field by checking CURFLD. My practice has always been to:

DataEntryLoop: !
RINPUT MAT SPECS$:MAT DATAFIELDS
if fkey=exitkey then cancel
if fkey=saverec then saverec
if curfld=1 then do the validate for field 1
if curfld=2 then do the validation for field 2
...
goto looptop

-- Susan

Susan.. you are correct about the attributes following the group number.

I missed that. However, tab seems to work okay without the T attribute, at least in version 4.2.

For now I suggest that you assign FKEY values and test for them before checking the CURFLD values. If an FKEY is found then don't process the CURFLD list.

That's a good workaround. I'll do that.

-- Susan

Susan,

it looks like curfld is returning the field that the cursor was in just before you clicked on the radio button.

So you're clicking on the second radio button, the cursor is still in the first radio button from the last time you clicked. It now returns fkey for the radio second button, and curfld for the first one. The next time you input from your radio buttons, your cursor is now left sitting in the second one. So now when you click, you will see a curfld of 2 and fkey of whatever you clicked, and the cursor will be moved to the next field next time you input.

Does that make sense?

You can test this theory by moving throughout the fields (by pressing TAB) and then clicking on a radio button and you should see the curfld of whatever field you ended up in from the tab key.

I'm not sure why they designed it this way because i'm not sure why you would ever want to know where the cursor was at the time of the radio buttons click event, but it seems like it might be useful.

Perhaps you need to see NXTFLD instead of CURFLD to get the values you want.

Gabriel

Susan Smith wrote:George,

I tried your example and though I DID get better results, they still were not what I expected. Your example had the two sets (of two each) radio buttons followed by a text field. I get different results when I click on radio buttons than when I tab through them. And I can't seem to figure out the pattern. At first, when I clicked on the 1st radio button, curfld=4. But when I click on the 2nd,3rd and 4th, CURFLD is 1,2,3 respectively. So we were closer, though I'm not sure why. Is it the "X" attribute that you added to the radio buttons? But then I tried navigating through the fields with tab and the curfld values changed in a different way. I confess that I'm not that familiar with the "X" attribute and I'll go look that up. I use the "T" attribute regularly in my RINPUT statement processing to handle my entry loops.

Perhaps Gordon is right and this just needs some looking at from Dan. The way that I would EXPECT it to act, based on other windows programs, is to be able to tab through the buttons with focusing visually changing. And if I either click on a button OR press space bar while it has focus, then I would expect CURFLD to fire. I assume that there should be ONE curfld value for the entire radio button GROUP, but programmatically, you can still get around that if there were one for each separate element/button.

-- Susan