Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Tab order issues mixing CG and IW components
Hi there.  I searched through and found other threads on this subject but nothing that really assists my situation.

I have Delphi 10.2.3 and IW15.1.7 installed.  In the designer I set the CG and IW tabs to the order I want but at run-time, there seems to be an order of CG and an order of IW that can be a bit random at times and pressing the tab at run time jumps around on the screen depending on the mix of field types.

In the designer or IDE, when I go into tab order, only CG fields are listed in this and never IW.  This appears to be the issue.  Is there a way to turn on the tab order in the designer for IW components so then the mix of components at run-time are rendered in the correct order?

If I have a region that is only CG or only IW, then all is fine at run-time and I can tab from field to field in the order I have set in tab order.  Only in a mix of field types does this odd issue surface.

I am just questioning here in this forum since I cannot get the IW components to list in the taborder tool in the IDE suggesting an IW issue.  I have worked around the issue for a while but the client noticed now for an area that I cannot work around and have to resolve this issue now.

There is not much we can do there other than creating a workaround in the IDE (i.e. creating a new "tab order" menu option for IWForms and controls)

Delphi only displays TWinControl descendants, not TControl ones. All CG controls are TWinControl descendants (because they descend from TIWCustomRegion which is also a TWinControl).
Ah OK.  I see.  That explains allot.  I knew that it felt like CG was doing something different.  In general I try to use IW only fields but at times I have to mix in CG usually because of the ajaxrerender event they have or other reason.  Thank you for your quick response!  Too bad the tab order was not used religiously when the form renders fields in that order.  Cheers.
At run time it should behave as expected, though. Unless two or more controls are sharing the same tab order value, at the same container level.

Like you have 1 IWRegion with tab order 1 and 1 CG control with the same tab order, both parented to the same container (because of the TControl/TWinControl inheritance it should be possible to do it). In that case it will behave like random because the browser will likely honor the first element in the DOM tree with that tab order.

Is that the case?
This is the new tab order editor which will be released in the next update (design stolen borrowed from GExperts editor). Hopefully it will make things easier

[Image: tabordereditor.png]
Cool new feature!
Ah right on!  Thank you.  I have been working through my form to see if I can see if there are any duplicate tab orders on the form so this feature would make things so much easier to move tabs around and see the lay of the land.  In CG there is also other properties called tab stop and tab index which makes things a bit confusing.  Once I work through my form to see if there are any duplicate tab orders, then I can see if your suggestion worked.  Over the weekend my time is more limited on father duty so tomorrow I should be able to finish this sweep off.  Cheers!
Hi there.  Quick note that I am on IW 15.1.12 now since the start of this thread.  I was just getting nowhere on my complicated form so I abandoned that and went to a more simple form that has way less fields and options.  Just a basic data entry form that has to use the CG dropdown for fields that can show a fancy graphic tag for multiple values and another dropdown that items are dirrived from a dataset.  There is also a CG edit field mixed in there since I needed the fancy extended masking.  All are placed on a CG region that has no tabstop or tabindex set.

CG has 2 extra tab overhead boolean properties that can be set called tabstop and tabindex.  I have tried every technical combination of these settings and when I the tab order works depending on setting the browser just chooses whatever tab order it wants and I have no control over it (is the same order each time though).  The only thing that I am thinking is that the fields maybe are being displayed in the order I inserted them somehow on the form in design but the dfm file does not seem to gleam any nuggets here.  The dropdown that has the dataset is the only one that I can get to work in the tab order I want.

I read somewhere that if the IW friendly name property is a duplicate with another IW field that this can cause browser confusion with tabs.  Since this field sometimes sets for the name and sometimes not, I swept through for this too.  No dice.

There are no duplicate tab order numbers anywhere that I can see.  Looks like there is no way to control the tab order when CG is added for some reason.  I give up.  I asked CG what this extra tabindex field is for but there is no longer anyone there from what I am seeing so I won't hold out any hope from them answering for this product.

From an engineering viewpoint is there anything that can be done to force the browser to render its fields in a specific order so then the tabs will work?

If tabindex attribute of HTML elements is not set the browser will still try to find a logical way to deal with tab stops. It will use the position of elements (similar to what Windows also does). Each browser has a different implementation so I can't guarantee that they will behave the same though.

I don't know exactly how CG Dev renders tabindex attributes and how they organize it in their components (if they use any internal logic or rely on IW for it - I suspect the former)

Sometimes it helps to set the TabOrder property at runtime inside OnCreate event of the form (because it works slightly different). Have you tried it?
Ah, interesting idea.  No I never thought of setting the tabs in the create event assuming the designer would carry through to run-time on this.  Now that you mention this, I remember a sliver of a thread in a forum somewhere talking of setting tabs at run-time.  I think you are correct that CG is doing something on its own given the behaviour.  Thank you for the tip about the browser using the position of the elements.  I can feel more what is going on behind the screen.  I will set this on my more simple form in the create event as you suggest and then update this thread on my findings.  Thank you for your attention to this Alexandre and going the extra mile.  I really appreciate it.  Cheers!

Forum Jump:

Users browsing this thread: 1 Guest(s)