Note this was sent yesterday… but with the wrong account chance it didn’t make
it to the NUG — max
> On Jan 16, 2017, at 7:47 PM, Chip Scheide <4d_o...@pghrepository.org> wrote:
>
> not quite what I was saying....
>
> The Tab_Manager() routine would handle whatever is needed to load related
> records, calculations, set enterability etc for the current tab.
That is what I thought you meant by Tab_Manager, Chip. And of course, I did not
have a Tab_Manager routine in the object method of the tab-control, nor was
there an on-load box checked in the events of the Property List of the
tab-control; the only event checked was on-clicked, the labels array was
defined in the property list and the standard action was goto-page. Yet… after
a record-change button click, and various object methods execution (for other
form objects), plus the form method's on-load execution... the correct
related-record content loaded in the subform located on the page currently
active prior to the record-change button click; be it page 2, 3, 4, etc.
V15r5 behavior is not as magical, if you will. Briefly, after a record-change
button click, the tab-control, when without explicit guidance via code, is set
to 1 (page 1); that is, the highlighted tab (OS X) becomes tab 1; the
subform/page displayed remains on whatever it was prior to a record-change
button click, and, the content on that page is not auto-updated to reflect that
a record-change operation has occurred. Clearly v15 expects explicit guidance
(code) for whether or not to remain on a particular page and to load
related-record content.
While I think I understand the import of the Tab_Manager routine you describe,
I did not have one instantiated and yet the intent of a Tab_Manager routine
occurred... in v12… apparently magically. As I said earlier I will go back and
look again for something responsible for the behavior.
> The current tab being the array 'Tab_Control'
>
> ex:
> Tab_Manager(Tab_Control)
>
> in Tab_Manager
>
> $Current_Tab:=$1
> case of
> :($current_Tab = 1)
> :($current_Tab = 2)
> :($current_Tab = 3)
> etc
> end case
>
> Since Tab_Control is an array (the displayed tab markers.)
> the last clicked tab is the value in Tab_Control.
>
> IF during the On Load, or ON Unload, or On Verify form events
> you do NOT clear the array, then when going to next/prev record Tab_Control
> will STILL HAVE the last user selected tab, and the tab control will display
> this tab (2 or 5 or 10).
In v12 that was my experience too. But, related-record content would auto-load
correctly for a page, whatever it was, without an object method.
> IF you clear the array (clear variable) or
> Tab_Control := 0 (or 1)
>
> Then the displayed tab will be the the first tab.
Makes sense, however, I can not speak to these facts as I never had need to
clear the tab-control array (the tab labels array, and the value of the
last-selected tab) so I can only take your word for it.
> NOTE : someone mentioned using Get Current Form Page
> This will only work if your tab control also changes page, on a multi page
> form.
> I do not often create multi-page forms, this would not work for many of my
> entry forms
Keith Culotte mentioned form-get-current-page, and yes, in reference to a
multi-page form. The input form we are discussing is one such, and Keith was
pointing out that obtaining the currently displayed page, via FGCP, in the
on-load execution cycle, in a tab-control object method, is the necessary step
before deciding how one wants to control the tab-control in an on-load cycle.
Again, thanks for you reply and explanations, Chip. My apologies if I was not
being clear enough.
max
>
>> Thanks for your reply, Chip.
>>
>> If I’m understanding you correctly, Tab manager(Tab_Control) does
>> the work of loading related-record data after a record-change button
>> action (next, previous, etc) on an input form, and your experience is
>> that the related data would not load otherwise. Am I getting that
>> correct?
>>
>> If that’s the case then all I can say is my experience with v12 for
>> a continuous string of years has been different. I’ll go back and
>> recheck form and object methods just to be sure… and report back if
>> I find anything. In any event, thanks for your reply.
>>
>> max
>>
>>
>>> On Jan 16, 2017, at 6:11 AM, Chip Scheide
>>> <4d_o...@pghrepository.org> wrote:
>>>
>>> no this is not the case, in v12 even.
>>> Tab controls are arrays, as such, if you/user selects a tab and you do
>>> not clear/reinitialize the array between record access, then it has the
>>> last selected tab as default.
>>> ex (pseudo code):
>>>
>>> :(on load)
>>> if (size of array(tab_control)=0)
>>> array text(tab_control;5)
>>> list to array("Entry_tab_Titles";Tab_Control)
>>> Tab_Control:=1
>>> end if
>>> Tab_Manager(tab_Control) // does work to display correct info on tab
>>> page
>>>
>>> then on the second access of the entry form (next/previous record) the
>>> tab control will still have whatever value the user last selected, and
>>> the above code will setup the tab accordingly.
>>>
>>> On Fri, 13 Jan 2017 13:48:41 -0900, Max Morrison wrote:
>>>>
>>>> First, I’d like to verify a possible change in behavior going from
>>>> v12 to v15… It use to be the case that Tab Controls would maintain
>>>> the currently displayed page across new-record load events, on an
>>>> input form. In other words, an input form is displaying a record with
>>>> a tab control on page 2. In v12 when I click the next record button
>>>> the next record displays with page 2 of the tab control still active
>>>> and highlighted. In v15 my tab control is reverting to page 1. Is
>>>> this behavior the same for all or just me?
>>> **********************************************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
