Hi -

I would like to know whether there is an "easier" way (than I am using) to identify "unknown" LE's.

For example, I was just working on a form that revealed an LE3 and I had abolutely no idea what it was.  The only way I could locate it was to go through (in the designer file) field by field until I finally found what field was bound to that element - thus allowing me to assign a more appropriate name to the LE.

Unfortunately, it was one of the last fields in my database, so it took considerable effort.

Is there an easier way for me to have done this?

Thanks!

Mark

I am drawing a "complete blank" on this one.

What is a "run time" copy?  Do you mean the database itself as opposed to the DSR file?

What/where is the "spec handler?"  Perhaps I've seen and/or used it but am not sure what you are referring to.

If it's an easier way to identify LE's that I can't recognize, I would certainly want to know how to utilize it.

Mark -

You're killing me!!!!

Every time I think I am progressing well with the use of Sesame you give me an answer that makes me feel like I am completely retarded and to such a significant degree that I am not even able to realize it.  lol

This is another situation where I thought I had an "understanding" of process/procedures and your answer raises many questions in my mind.

---

First, I always thought that all design work (forms, adding fields and/or layout elements - whichever is which), programming, reports, etc. HAD to be done in a DSR file.  I suppose - in my mind - it followed that the DSR file would always HAVE to be the "master."

Even though I am running these programs as a "stand-alone" application - without worrying about networking ... I do all my design work in the DSR file, save it, and then reconcile my DB file.

Now - if I understand some of what you are saying - I could use the DSR "program" to OPEN a DB file and do my design work right within the DB file itself.  Is that correct?  If so, it is a totally "new" concept for me and I 'll have to give it a lot of thought and experimentation.

---

As for the spec handler, I of course have used it - I simply never knew it had a name, because it doesn't appear anywhere on the form.

---

Now, continuing ....

Quote:


That's a bit of a help but here are two inherent problems with this.  First (at least in my forms, perhaps because of choice of color or whatever), it is very difficult to see the highlighting around the LE.   So, I still have to look from LE to LE - one by one - to "find" (if my eyesight is working properly) the highlighted field.

Second, it seems to me that the highlighting occurs only when a field (LE?) label matches what is in the list.  For example if I click on Cell the LE with a label of cell (bound to a field also called cell) is highlighted; HOWEVER if I click on CommentsCell  (in the list) the LE with a label of Comments (and there are several LE's with that Label) is NOT highlighted even though it is bound to a field with the name CommentsCell.

Likewise (and since I LOVE tabs, I use them in most of my databases), if I click on something in the list which is on a tab that does not have the focus, the corresponding LE is NOT highlighted even if I open the correct tab.

---

The attributes table looks like it "might" be a help although I'm not sure it would in the particular situation I described.  BUT, how on earth do I find it (without having to look through your earlier posts).  I could not find anything that would "obviously" lead me to it in the database and I could not find anything in either the User Guide or the Programming Guide that referred to it.

P.S. NEVER MIND THAT LAST QUESTION.  I just re-read your earlier reply and see that it WILL be available in 2.0.  So - when can I get my copy of 2.0  Huh?  Huh?  Huh?    lol
OK.  Let me have it!  lol

Carl -

I follow some of what you are saying, and some I don't.  But I am "overwhelmed" with new information at present so I just can't explore all my questions.

There is one point, though, I would like to clarify.  If you open your DB file and then select the matching Designer file and then save it - are you Saving it to the same file name and thus overwriting your master database OR are you saving it with a different name?  If you are saving it with a different name (which I would think is "safer") then how on earth do you know the name of your MOST RECENT and MASTER file?

I believe Bob Hansen appends #'s to the name like Master1, Master2, etc. which would mean that the highest number would always be the most recent (master) file.  BUT, what if you are doing "lookups" to the database?  Do you not then have to go in and modify the lookup statements?  OR - do you copy your highest number database back to a "standard" name e.g. have Master be your master and then copy Master10 back to (and overwrite) Master ... and then copy Master11 back to Master, etc. etc.

Arrgghhhh!   

Mark -

The comment about making me feel retarded was just a stab at tongue-in-cheek humor.

First of all, NO one can MAKE me feel anything.  Only I control that.  Secondly, I have too much self-esteem to ever feel retarded ... and, certainly, I mean no offense to anyone who is indeed retarded.  That's just another "condition" of life and we ALL have our own "conditions."

But, the truth is I am amazed at how I thought there was only one way to approach database design and that was via the .DSR file.  As I said earlier, I will have to give this a lot of thought and decide whether I want to understand it better and then play with it.

But, assuming I ever do work for someone on a network, wouldn't I then have to "revert" to the method I am currently using?  If so, I feel that I am better off with one, approach.

Also, as asked before, what if you have lookup statements to the MV01.db?

Spencer,

[quote]There is one point, though, I would like to clarify.  If you open your DB file and then select the matching Designer file and then save it - are you Saving it to the same file name and thus overwriting your master database OR are you saving it with a different name?[/quote]
If I want to modify "MyApp.db", I almost always will:
1) Open SDesigner.
2) Select the 'Open Application' icon.
3) Click on "MyApp.db". (Note that this is the DB not the DSR.)
4) Click on "MyApp.dsr", then the 'Accept' button.
5) Select 'Yes', to replace the existing file named "MyApp.dsr".
6) Make any modifications I want.
7) 'Save As New Application'  to a test file named "_Test.db" (the underscore makes it stay at the top of the list, for quick & easy access in a large list).
8) Click on a desktop icon that I have set up just to launch the "_Test.db" file, and test the changes I just made.
9) Go back to SDesigner (which is still open) to tweak the code if needed.
10) Make any needed changes. (At this point, the test app is still open in Sesame runtime, so I can use it for reference purposes like the way Mark mentioned.)
11) Close the Sesame runtime session that had the "_Test.db" file open.
12) 'Save As New Application' -OR- 'Reconcile Existing Application' to the "_Test.db" file, depending on whether or not I want any test records I added the first time I tested it, to be there for the next testing.
13) Repeat step 8 above.
14) When everything is testing properly, I 'Reconcile Existing Application' to the original working application named "MyApp.db".
15) If I completely screw up the design or code, I can simply repeat steps 3 and 4 above, to get back to the previous design, and start over or leave well enough alone if the new idea wasn't as good as I had imagined. :)

I rarely use Preview Mode, because I have found in the past that (besides the X-Family of commands) there are some things that work slightly different in Preview Mode and runtime. I will use Preview Mode to "see how thing look" after layout changes, but I almost always test changes to code in runtime. Plus, I use a lot of X-Family commands. Hence, the reason for the "_Test.db" file and desktop icon to launch it.