Is there a way to change the name of a tab page? Not the label displayed, but the actual tab?

As Sesame adds tabs it names the second one TabPage0, the third TabPage1, etc. If a tab is moved it keeps the same name, which is fine for the end user but confusing for programming--I have Tab, Tab7, Tab0, Tab1. Their labels are 1 ... 2 ..., etc.

I tried the Name option on the Property Editor but it has no effect.

I'm just getting started with SBasic programming.  I have 9 tabs and I'm interested in opening to "2. Search" -- which is TabPage7 and also having it automatically switch to Search Mode every time that tab is activated.  (Some of the folks at our office aren't familiar with fancy Windows functionality such a Ctrl-C, Ctrl-V, etc., so I think it's only reasonable that at tab titled "Search" should work in search mode, not Update.)

Right now I only have the download version, so I ordered the guides today, since I find it a lot easier to grasp complex things from books than from a computer screen.

Yes. This is an update of part of a QA application.  Currently, data is originally entered into one QA database, then certain fields are copied to a QA database called Status.  I'm not sure of the full functionality yet, but it is my understanding that at some point certain fields from Status are then copied to a third QA database to do billing and/or they are copied back to the original QA database.

The Sesame application will basically be replacing the Status portion only. At the top of the main form is an "Information Bar" containing three rows of fields equivalent to the form QA Status uses.  Data that will be ported back and forth to QA will be entered and updated in those fields.

Below the Information Bar is a set of 9 tabs.  The first, 1. Home, contains about 3 additional fields that interact with QA.  The main one is a multi-line text field called Status Report.

Tabs 3-8 contain new fields that will not be ported back to QA.

The second tab is 2. Search.  This has a second set of LE's  tied to the same fields as the LE's in the Information Bar. In other words, the Surname LE in the IB and Surname LE on the search tab page both are tied to the Sesame db's Surname field. The Search page also duplicates ties to some of the new fields.  There are no LEs  on the Search page that are not on some other page also.

There are a variety of reasons why I have a search tab page:

First, this is a super-political work environment, where if the choice is "showing who's boss" or doing something logical, logic loses. If anyone complains even once, instead of the owner saying, "Let's see what we can do about this or if it's even worth looking into," the immediate reaction is to demand specific changes without looking at the overall form, etc.--from someone who has no idea of how to design or program.

Second, on the Search page (1) I have duplicated the fields they are most likely to actually use for searches, (2) made them longer for easier input to create Retrieve Specs, and (3) grouped them into search criteria types. I.e., Name-related fields are in one group surrounded by a labeled box, File Number/Account Number-related fields are in another group, Activity criteria are in a third group (Last update, Follow-up, Person who updated), and Type/Amount-related fields are in a fourth group.

Third, the logical grouping for data input and for searching will be different, so creating a Retrieve Spec with the data-entry form would be a pain.

Fourth, many of the data-entry LEs on other pages use combo boxes (and I won't be telling them they can add other text).  I really don't want people updating records from the LEs on the Search page because that will let them add non-normalized data.

Fifth, I think that if a tab is labeled "Search", it is reasonable for the user to assume that making entries there won't change data.

Sixth, I'm sure the users (including me) will generally want standalone form mode, which is a lot less cluttered.  Even just working with a copy during design, I am finding it confusing trying to remember when I'm in search mode and when I'm in update mode. (I do realize that the fields all clear when search mode initializes.) I'm still trying to figure out how to have @Mode() automatically update an indicator.

What I'm probably going to do once I figure out how to do all of it is  put two command buttons on the Search page for Prepare Search (equivalent to pressing F7) and Begin Search (equivalent to pressing F10) and have the Search tab automatically switch to Search mode when it receives focus unless the user is already in Search mode.

In other words, with a Search tab, the normal reaction will be to click that to start a search.  Doing that will automatically switch to Search mode.  Most searches can be set up only using that page's LE's.  If the user needs others, she'll click on other tabs and fill in those fields.  Then she'll click Search again to get to the Begin Search button.  Because it will already be in Search mode, it won't re-initialize Search mode.  (Of course, the user will also be able to use F7 and F10--I don't plan on disabling those.)

I'm not sure I follow you.  However, I think I want everything in the same tab group. Because of the field duplication, most of the time all the fields we will want to use in a search will be available on the Search tab.  But for some oddball searches we will want to include fields on other tabs.

I messed around a bit with @Mode and did manage to have a read-only text field that indicates which mode I'm in, so that should help setting up code that switches to Search mode.  My biggest problem right now is I just really have difficulty trying to picture the interrelationships of the different commands, etc., from a computer screen.  I find it much easier to grasp that when I see it on paper.  The books should be arriving next week, which will definitely help.

Also, now that the import/export questions have been cleared up, I'll be mainly working on that for awhile.  Besides, none of this is official yet, so it's not like I have a deadline or expect that the switch to Sesame will happen in the next few months.


By the way, please move the Search Tab discussion to a new topic. Others might be interested in the Search Tab approach and it's not obvious from "Change tab name (not label)" that the topic has changed.