Here is a challenge!

Let's say I have a form with sub-form. On the screen sub-form only shows 13 lines.

Question is, would it possible to restrict the users from entering data into 14th row or more in the sub-form.

In other words, I only want the users to enter records up to 13 lines.

Download Sample!

We solve this with new DE8 features.

A subform works as follows. If you fill all the visible rows in a subform it will move one up and give you a "clean" new row at the bottom. As long as there is a clean new row at the bottom it will not allow you to scroll further.

So our hack is simply to hide the row at the bottom so you won't be able to access it and hence to able to populate it. This will forestall DataEase's attempt to add a new row.

We do this by hiding the Record object in the subform for Row 14 (we wanted 13 row so we make a subform with 14 and hide the last).

in DE8 we have added the ability to pick which Object or Object Clone we want to manipulate in the form. All objects follow a strict object Hierarchy which is simply right to left, top to bottom inside a Container class.

This might be slightly complicated to get the hang of.

In a form without subforms, the object hierarchy will be straight forward left to right, top to bottom. A object all the way to the right which is one pixel higher than one all the way to the left will be ahead in the object order.

When you have a subform, the rules will be the same inside a subform. If you have two subforms next to each other on the same pixle line, the one to the left will be parsed first and then the one to the right. If the one to the right is one pixel or more higher up it will go first.

There is one "big" flaw in the DataEase object model and that is that all Record objects is called Record1 (actullay it is called Record on creation and magically renamed Record1 on first reload of the form....but that is another story). In all practical terms it is ALWAYS called Record1.

So if you have a MainForm with a Subform (like the sample) the first Record1 will be the main record and the second Record1 will be the first Record in the subform.

THis is why we in Manip hide Record1#15 and not Record1#14.

Have a look at the sample and see if you can figure it out.

This is perfect! And this is what exactly I was looking for.

But, how do we handle two sub-forms?

What I meant was;

Sub-form1 with 10 lines and I want to hide the 10th row

Sub-form2 with 14 lines and I want to hide the 14th row

I guess it is one of those undocumented features :-)

After trial and error, I figure this out. Sub-form1 is RECORD and Sub-form2 is RECORD1.......

Very strange numbering. I thought it would be RECORD0. That didn't work.

Anyways, I hope this stays in the future DataEase versions.

Hi Arul. 

It is all there in the first reply.... I guess you read to fast ;-)

1. Record object is always called Record1, and they cannot be renamed. The slight confusion is that when you create a form or a subsequent subform, the RECORD object is initially named Record...BUT! It will change name the first time you close and reload the document. Why? Only God knows, but it has been like this forever.

So for all practical programming reasons, you need to work with Record1 only!!!

So the RECORD object of the Main Form is Record1. Each clone of the Record object in a Subform is called Record1 and in any subsequent Subform.

Ex. If you have a form with 3 subforms, with 10, 15 and 20 rows, you will have 46 objects named Record1 in your form.

Lets for simplicity put the subforms under one another on the form. The the last Record object in each Subform would be

Record1#11
Record1#26
Record1#46

PS! If you move the subforms in the form so they change place in the object order, this will no longer apply!

2. All objects in DataEase Object model gets automatically named, but some objects can be renamed and some can't.

Forms, Record and TabControls cannot.

Form will be named Document Name.
Sumbforms will be named the same as the relationship they are created on.
Record will always be named Record1 (after first reload of document).
TablControls will always be named Tab Control but with a incremental number 

The best way to find the object names is in the OML editor. There you see the order and the names.

Yes, you are right. I read things fast. Now it seems to be working fine with TAB.

But, when you use the DOWN ARROW, it goes into those hidden fields in that sub-form. How do we stop that?

Our fix for it is to fix SetState("ObjectName","Disable") and Enable so you can disable rows in a Subform.

And also look at "hidden" fields. For some reason you can get into hidden fields (on tabs too) by using the arrow keys etc. This is obviously a bug...

Problem now is that this feature of SetState disable and enable the entire Subform.

You might be able to fix it by snatching the keystroke for arrow down on the last row, but to be honest it is not worth it.

I tried something like this and it works;

MoveObject("Record1#25","C","C")

he,he.

Before I ridiculed you I tested it and it does actually "do the trick".

To be honest, this is more "pot luck" than anything, but as my old boss said when he looked a the majority of applications of the big pile he had received for a new position in the waste bin where he had unceremoniously and without a second glance deposited them:

"Those people are unlucky.....and we don't need unlucky people!"

To be honest, to me this is a little of what DataEase programming is all about.

"Try the implausible and you will achieve the impossible."

But with so many discoveries made by chance there is really a logical explanation...he,he.

The original problem is that Arrow Keys don't follow the tab order, they simply go to the next object in the DOWN or UP direction.

What you did was to move the Last Record object to Centre of the Parent object.



If you remove the hiding of Record1#15 you will see this. Try tab /enter and arrow keys.

With TAB/Enter you will see that it goes to the last one last anyway, but with arrows it will do it after 6.

TAB/Enter respect the hidden field so it will never go there in the first place (when hidden) but Arrow Key doesn't but now it is outside its order so you are all good.....but no.

If you try to go arrow down the list you will see that it still gets focus but now around row 7....

Download Updated Sample!

Since you don't seem content to wait till we fix SetState("Object","Disable") I guess we had to find you a workaround.

Since the problem is that the fields get focus, we can simply bounce it back when they get focus.

We put the following script on the Fields GotFocus Event.

We simply check the RowNumber and if it is 14 then we use SetFocus() to set focus back to 13... ;-)

You will however have to do this for each Editable field on the record.

We also put it on the KeyDown event on the Record itself. That too worked to a point, but as it would need one Keydown on the record itself the field got visible till first keydown and then it moved back up.

Try Field two in the app and you will see this.

>>Since you don't seem content to wait till we fix SetState("Object","Disable") I guess we had to find you a workaround.

I don't mind waiting if this function becomes available in 2015 ?

Just winding you up Arul ;-)

This should work fine, so no reason not to use it.

SetState() is not a priority fix at the moment.

Trouble with SetState("Object#n","Disable/Enable") is fixed in 8.5.1.1989.

This will however not be available until the RC of DE8.5 Slipstream in December.

Hopefully the workaround we showed higher up in the thread will suffice for now.

This conversation we did while ago. It seems like lots going around the nice feature called SUB-FORM in DataEase. 

So, we do really need more functionality around Sub-From.