I am toying with some of them, mostly for the ready made, iphone and ipad layouts. But I see a lot of /* */ comments in the scripts where values should have been and values set to "" in script steps, in the contact starter solution for example. 

 

Do I conclude correctly that they do indeed require modification to run properly?

No, they should run fine as is, for the functionality provided.  There is nothing wrong with comments in calculations and scripts; in fact, it is a good thing.  And just because a script has "" as a value doesn't mean it is wrong … sometimes we WANT to clear out a field's value.

 

Can you provide a specific example for us?  In truth, the functionality in those files should be recreated into new clean files and they should be used as examples instead of building on top of them but I can see how it might be appealing to use them.  :-)

"In truth, the functionality in those files should be recreated…"

SHOULD? No.

Good grief.  If you are going to comment, please put a reason you say no.  I meant the file should not be used but use their ideas on iPad size and so forth to build a new one.  I do not personally care for the structure nor naming but that is not for me ( or you ) to decide.

 

Just saying 'no' is a cop out, Bruce.

Exactly.

 

YOU prefer not to use example files.

 

Other people may have different preferences. They may accept the example file structure; or they may feel more comfortable evolving the example files, immediately or as they learn, over time.

Now wouldn't it have been easier to properly respond to begin with?

 

I stand by what I stated prior to your response.

they may feel more comfortable evolving the example files, immediately or as they learn, over time.

 

I think anyone aspiring to manage their own solution would be well advised to start from scratch. That way they know exactly what they put in and why. "Evolving" the example files is much more difficult, IMHO. You'd be constantly asking what is this or that good for (and not always get a good answer...). How did this thread start? Ah.

I agree, Michael.  I've been working with folks who have modified starter solutions and they are more confused than if THEY built it so THEY knew what each portion meant.  The Starter Solutions are great to see how to identify the device (by reading scripts) and how relationships work in general but they are examples.

 

There is also this:

 

https://fmdev.filemaker.com/thread/69468?start=0&tstart=0

 

Of course, how many new people will know to check for this Knowledge Base article before building upon a Starter Solution?  

No, they should run fine as is, for the functionality provided.  There is nothing wrong with comments in calculations and scripts; in fact, it is a good thing.  And just because a script has "" as a value doesn't mean it is wrong … sometimes we WANT to clear out a field's value.

 

Can you provide a specific example for us?  In truth, the functionality in those files should be recreated into new clean files and they should be used as examples instead of building on top of them but I can see how it might be appealing to use them.  :-)

I am actually recreating them in my own database, and using their layouts, but I have understand the rationale behind some scripts so that I implement them the same way too. Esp. interface elements scripts.

 

But, I am quite sure, I was wrong in my initial post, as this behavior is onlly demonstrated in carry over scripts. I guess after a few hours of work I got confused and thought I was working with the scripts in the original starter database. So, I ll mark this as solved.

Having said that, I have noticed certain bugs or inconsistencies in the starter solutions, I am dealing with the personnel one, anyone notice this too?

That's rather vague. Like what in particular?

I provided a link to Tech Net which requires a login so, although Tech Net is now free, in case someone does not wish to register, I will fill you in:

 

I had discovered corruption in NEWLY CREATED files from Event Management. Corrupt before anyone even used it; immediately upon its creation.  There ended up being two corrupted starter solutions.  FM provided a fix and released a KB, "The article includes links to download clean copies of the Event Management and the Research Notes starter solutions…"

 

http://help.filemaker.com/app/answers/detail/a_id/11549

 

Hey, fmow, did you think of checking for a knowledge base article before using a starter solution?   Yes, there are anomalies in the starter solutions - mostly small stuff where objects have been duplicated layout to layout and were stacked - the kinds of things we've all done.  And if gradient is set on a portal the entire portal highlighted when hovered as if it was a button but it wasn't (cool grey, Invoices, I think) … a few things like that.  

 

When I realised that a starter solution is probably a 'save a copy as' and can therefore inherit all of the swiss cheese (per Ray Cologon) and potential crashes experienced by the originating file, steering folks to creating their own seemed even better idea.