Hi,

If you have a screen and some fields with the mandatory input flag set, say on field 3, then it is standard ProIV, that if you press the 'DO' (F3) key on the first field of the screen then mandatory check is not done.

Does anyone know how to override this behaviour, since I want my field 3 to ALWAYS be mandatory?

Thanks,

Rob D.

You could consider using an EOD/Exit logic to trap this.
If FnKey 10 (and/or any OK button FnKey) was issued, check any required fields are populated and if not issue an appropriate error message, fld jump etc, then ABORT_EXIT()
This will keep the user in the screen.

HTH

Andy

Hi,

Yep, I thought of that...

But, I wanted a more 'Generic' solution, so that we did not have to code for each mand. field on each screen,

Thanks anyway,

Rob d.

OK, plan B...
You could try using the ForceWrite method if you are on 5.x - it applies to a cycle and has to be set before you call it - so function entry is the best place.
Syntax is MyCycle.ForceWrite()

This will make F3 explicitly save. It's also useful for single field paging screens as changing data then F3ing or arrowing will still get the data written away...

Plan C.
There is no plan C.

Andy.

Note: this from someone who hasn't struggled with a serious ProIV screen in a long time and didn't try now..

If, as you seem to imply, your mandatory check would be done if you EODed from your second field.. is it not possible to add some kind of 'dummy' first field to dupe ProIV into doing what you want?

Could this be an issue of change-mode + last-read-field or maybe needing auto-repeat + override (to make ProIV think it's an input field)?

Just throwing ideas over the wall..

rob... i know what you are doing since basically we are writting for the same apps.

what i've thought of before, though i haven't the chance to code it in, is in the logic in set a variable to a value (say 'N'). then this value will be set to 'Y' right after the last mandatory field i have. then on the EOD/Cancel logic i can then trap the value of FNKEY and validate the value of the variable. then apply the appropriate message and logic if necessary.

sounds logical?

Ahhhh...

That looks like what I need.

I'll try it tomorrow.

I could not find that method in the 5.5 Documentation though. Is it supported do you know?

Thanks,

Rob D.

additional info... also it should also be taking care if the function was triggered to add or maintain an existing record.

Hi Rob,

As an alternative to the ForceWrite method you can put the following into general check logic of the mandatory field :-

CHECK-INPUT
IF ORD($INPUT) < 32 OR ORD($INPUT) > 126 THEN  
   GMSG(1)
ENDIF

You'll have to check whether any of the associated ASCII characters after 126 are valid entries for your system though. I bet you're glad you won't have to worry about Ö, Ä and Å!!

Cheers,

Lee.

Errr,

What would that do?

It wont fix my prob.

Its to do with the timing cycle on the first field. The first field is not mandatory, its the 3rd (or what ever) field that is mandatory.

Rob D.

Hi Rob,

Sorry but from your email I assumed the first fields were display only. However, since the problem occurs only on the first enterable field the solution can be amended to having the following in general check logic of the first enterable field :-

CHECK-INPUT
IF @FNKEY # 9 THEN 
   IF (ORD($INPUT) < 32 OR ORD($INPUT) > 126) THEN
      IF $FIELD3 = '' THEN 
         GMSG(1)
      ENDIF
   ENDIF
ENDIF

Where the global message would read something like
'ERROR - Please Enter All Mandatory Fields'.

However this is getting a little messy as a generic solution so perhaps the ForceWrite method is a better option.

Cheers,

Lee.

I use Superlayer so don't know if this will help or not but I put an enable(&#@SUPP-EXIT) in the logic before of first screen field and a disable(&#@SUPP-EXIT) in the logic after of the last mandatory screen field. That appeared to fix the problem for me.

Hi

One of the things that I learnt about PRO-IV the 'very hard way' is that it treats the first entry field completely different to subsequent entry fields. F3 on the first entry field means exit the screen, don't do any field logic, don't check for mandatory fields, don't write the current record. This is exactly the opposite of what you would get if you performed this operation on subsequent input fields. I have found this problem extremely frustrating in paging screens where there is a single 'windowable' field. The window say is a further paging screen that accumulates figures onto the parent record of the aforementioned screen. Users have the tendancy to push F3 when they exit the window. Guess what? ... the parent record does not get written away and all the accumulated totals are lost. I have tried to trick PRO-IV by having a dummy MI field before the window and then skipping over this field. Guess what? ... PRO-IV still treats the window field as the first input field. I haven't migrated to any version above 4.x so I cannot use FORCEWRITE() which sounds like the answer to me. Anyone have any other smart ideas?

George Walton Snr.

more smart ideas?... probably not George... I reckon you'll probably not fix it without some compromises or an upgrade... I've learnt the very hard way too...

The behaviour on the primary field is a deliberate design optimisation in the PROIV kernel to avoid unneccessary data writes, and not one which is easily altered.
FYI there is also a problem with arrow keys when changing data on paging screens where the primary field has not had direct keyboard entry - e.g. a checkbox, or window data to field or 'hidden' data only return. In such circumstances record navigation also uses the 'no write' optimisation.

I'm sure I've tried all combinations of EOD/Exit logics,check-input's and field skips conceivable to man or beast, and I'm pretty sure the optimisation can't be worked around - completely anyway - although there might be something that will suit your particular requirements...


You could return the window data through $INPUT to force the cursor off the field (and so then do the write) but that would mean the user would have to select the record again to alter anything. A minor inconvenience compared to losing the data though perhaps.
You could also write the total to the parent record on the way out of the child window to ensure keeping the calculated value, and FLD(@FLD) to repaint the value.
In EOD/Exit logic trap Escape (if you are aborting an add) and do any clean ups you might need, if it's a change only screen don't bother. Alternatively you could call the window in window logic, pass back a flag from the window if the data change and suppress exit & cancel if set (still in the window logic) ... then allow them again once you get to the before write on the parent file. probably won't be particularly user friendly though...

Like I said, you'll probably have to compromise...


Primary field is always regarded as the first field you actually sit in for input - so dummy field and field skip ideas to try to fool the kernel don't work!
Also you must have just typed data into the field when you hit F3/navigation keys for it to recognise its data content has changed - so in your case you couldn't pass data back through $INPUT and then FLD jump back to the field if you want to keep the record open after the window - doing that just resets the internal 'primary field has-input' flag, and we're back to square one.


In answer to Rob's questions too:-

ForceWrite was implemented to address exactly this sort of problem. It was not possible to change the behaviour of the primary field itself and catch all possibilities for changed data - therefore the cycle behaviour itself was changed... The data change could be from a gui object (e.g. checkbox), window return or even a global call - far too many things for the kernel to try to keep track of.
So what ForceWrite() does is to make each iteration of the cycle do a full pass of the timing cycle, except when ESC has been issued.
This means that if you sit on a paging screen in change mode and arrow through the records, every record visited will be updated. This is obviously slower, and why it wasn't the normal behaviour of the kernel - also because you will always be updating every record, be careful!

As far as is it being supported, it was added in 5.0 so VIP's logic editor could be written as single field paging screen. It's available in the property/method picker in both Studio 5.x and VIP, so it is available to be used - it does look like it missed the manual though!

Paging screens were the original 'problem area' to be solved by ForceWrite, so it is likely that they are the only officially 'supported' cycle type. That said, AFAIK there's no reason why this behaviour modifier should be specific to paging screens - it's forcing a full pass of the timing cycle. That is just *my* opinion though!
There's no logic picker or gen restriction by cycle type -obviously it is for screens only - so see for yourselves as far as flat screens go. YMMV.

Regards,

Andy

see my reply to George...