I am not asking for you to disclose "specifics about a new release" I just want to know if they are showing any new features of a major release yet. I am debating if I should join again and seeing an early view of what's coming soon is really my only interest.

 

Also, is there a Tech Net private forum anymore or is their new public forum the only one?

 

Thanks.

Only place FM does previews is at DEVCON but that info is secured by an NDA. The DEVCON participants can't and usually don't reveal what they know.

I am referring to this: http://www.filemaker.com/technet/

 

If you are a member can you please tell me if there is currently an "Early View of an Unreleased Version" available so I can determine whether or not to join?

 

Thanks.

 

By joining TechNet you undertake to follow the explicit NDA that comes with it.  So the only way to find out is by joining.

My goodness, when do I see a copy of this NDA, after I check out?

It is part of the terms and conditions you agree to when you sign up.

There are two kinds of memberships. Community which is free and Developer which has an annual membership of $99.

 

For more information, click the more information button "FileMaker Developer Subscription"

Note that there is a somewhat "private" forum there that is open to certified developers only. It is receiving little traffic so far, but the revised site is still pretty new.

Automatic message

This topic has been moved from "User Group Central - Sponsored by FMPug.com" to "Member Lounge".

 

The FMPug is reserved for them to post announcements about their User Group Business, and not for posting  questions.

This says you can get 'early view of unreleased software'.  Does that mean the actual working program with a regular license or is it a mock-up version of the program that will expire or can't be upgraded?  What exactly would we get?  For $99, it would be a steal.  And same question about the server.

 

If it would mean I would get FM14 when it comes out, this would be a good deal.  I had already purchased the training series and our company already has FMS but it would be good to have FMS at home as well.

In the past when they did the "early view" it was a beta version with an expiry date.  So you don't get the full version.

 our company already has FMS but it would be good to have FMS at home as well.

The developer membership used to include a limited version of FMS for testing purposes. I think it is 3 seats, but I could be wrong.

A subscription membership still allows the use of FMS for development purposes with very limited connections.

The developer membership used to include a limited version of FMS for testing purposes. I think it is 3 seats, but I could be wrong.

 

Unfortunately the developer FMS now is limited to 1 concurrent connection for WebDirect of Go connections, which makes testing almost impossible (in my opinion) since one of the key things a developer needs to test is record locking with multiple users.   

record locking can be tested by locking the record in a copy of FMP easily enough...

record locking can be tested by locking the record in a copy of FMP easily enough...

 

 

In my opinion, there are enough substantial differences between FM Desktop Client, Go, and WebDirect that real-world testing is necessary.  Sure, you can test *some* of the logic using desktop versions, but that's no substitute for the real thing...

With the FDS server license you get 3 Pro connections, +1 Go/Web connection.

My first experience with FM has been with v13. Generally, how long is it between major versions (11-12-13, etc.)?

It runs approx. 18 months between releases. 

 

added word 'approx.'

Edited January 9, 201511 yr by LaRetta

Very good. I have an internal list of things I want to see in FM14!

Does FM every do "preview" presentations at, say, DevCon?

Sometimes.

In the past has there been any instances where a new version "breaks" compatibility with a previous version?  I.e., if you had an FMP10 database and when FMP11 came out, did it still work without any issues?

 

It seems that FM tries to maintain compatibility.  As someone who started at FM13, I didn't understand the point of the "global storage" option for fields, for instance (insofar as the contents were per user and deleted across shutdowns/startsup of FM), until I learned it was a way to have global variables before there were global variables.  And somewhat similarly with "repetitions" prior to portals.

I have an internal list of things I want to see in FM14!

 

Doesn't everyone. Don't hold your breath - many of us have items that have been on the list for over a decade.

 

 

As someone who started at FM13, I didn't understand the point of the "global storage" option for fields, for instance (insofar as the contents were per user and deleted across shutdowns/startsup of FM), until I learned it was a way to have global variables before there were global variables.

 

Global variables do NOT replace global fields. For one thing, you cannot use a global variable as the matchfield in a relationship. For another, global variables are not subject to user privileges.

Doesn't everyone. Don't hold your breath - many of us have items that have been on the list for over a decade.

 

Ain't that the truth!

In the past has there been any instances where a new version "breaks" compatibility with a previous version?  I.e., if you had an FMP10 database and when FMP11 came out, did it still work without any issues?

 

 

******* happens... so yes.  Which is why you carefully test your solutions in a new version before jumping on, and you wait and monitor the forums to see what issues are reported.

This is not a FM issue though, the same applies with new OS versions and sub-versions.

it was a way to have global variables before there were global variables.  

 

 

On that topic: global variables (as a means to pass parameters between scripts) = unstructured programming

 

(Hacker's monthly, issue 55)

Sorry, I didn't say that correctly -- global variables as a way to *persist* variables across scripts is what I meant.  I.e., for a given "script" I'll break it down into a bunch of sub-scripts if you will (easier to test, etc.), and use a global variable in this case, whereas if there was just a single mega script, the variable would be local. 

 

Is that considered OK usage of global variables?  I'm a self-taught hack programmer. 

And as to your article -- I learned how to program on a Commodore Vic-20 in BASIC!  Good times.

for a given "script" I'll break it down into a bunch of sub-scripts

 

In such case, using the script parameter to pass data to the sub-script and the script result to pass data back to the calling script would be much better practice.

 

However, there's only one script parameter per script and one script result overall - so this may not be as simple as it sounds when you need to pass several items.

In such case, using the script parameter to pass data to the sub-script and the script result to pass data back to the calling script would be much better practice.

 

However, there's only one script parameter per script and one script result overall - so this may not be as simple as it sounds when you need to pass several items.

 

Yeah, that's exactly the problem I had.  I had a recursive script, so the parameter had to be the "recursion" if you will.  But there was another parameter that was floating around, too, so I set that to a global.

 a way to *persist* variables across scripts is what I meant.  I.e., for a given "script" I'll break it down into a bunch of sub-scripts if you will (easier to test, etc.), and use a global variable in this case,

 

That's not good programming practice because your intent is for the scope of the variables to only live for your series of scripts but the real scope is the lifetime of that file's session.  So that forces you to clean up those variables when you are done.  If you forget the variable will live on past its intended scope and may interfere with other areas.

 

A better practice would be to pass the variables along between scripts as local variables so that their scope will never exceed the lifetime of the scripts.

 

http://www.soliantconsulting.com/blog/2014/01/all-variables-should-be-global-or-not

Can I clean them up by setting them to ""?  I just read this in another thread today.

mikedr,

This is one of the practices that I, as a semi-self taught developer, had to get out of also. I'll admit, I have moments of lapses, because it's SOOOOO easy to do...and I'm in a hurry to get something working.

 

It it only a matter of time before either the security element, or the variable-collision element, bites you. Both can be detrimental to your data, and relationship with your client/users.

 

It takes a little getting used to, but will in the long run save you a ton of time in debugging, clean-up, and head-banging. 

 

That is the way to clear them yes...but take seriously the recommended practice.

Understood!

 

Here's that post, though . . .

 

http://fmforums.com/forum/topic/91213-popover-button-behavior-with-script-triggers/#entry433310

Can I clean them up by setting them to ""?  I just read this in another thread today.

 

Setting a variable to "" deletes it. There is no other way to do so. However, the idea here is not creating it in the first place, thus not having to delete it.

 

Note also that although elaborate ways have been devised to pass multiple values in a single parameter/result, in most cases a simple return-delimited list will be quite sufficient.

1. It's careful to note that sometimes we may just answer a question on how to do something and not necessarily point out it's not best-practice. Though, often, we try to offer up additional observations if they seems necessary.

 

2. That situation wasn't passing variables between scripts. It was modifying the expected behavior of a UI element due to script triggers. More UI and less parameters of a script.

 

Understood!

 

Here's that post, though . . .

 

http://fmforums.com/forum/topic/91213-popover-button-behavior-with-script-triggers/#entry433310

in most cases a simple return-delimited list will be quite sufficient.

 

Until you need to pass a return-delimited result as one of the parameters.  Better to go with one of the established safe ways to do it.  I would not consider them elaborate; they're just a couple of custom functions that you paste into your files.

I would also suggest that this thread has become off topic from Halburn's post.

Can I clean them up by setting them to ""?  I just read this in another thread today.

 

Yes you can.  But now it is up to you to do it correctly: do it too late and you're toast, do it too early and your toast.

Pass them as local variables: no worries.

OR...it is on-toopic and everything is just cipher code so we don't violate NDA. LOL

 

I would also suggest that this thread has become off topic from Halburn's post.

  I like that!  

 

Halburn is certainly getting an ear-full he wasn't expecting with his question!  Mostly I think it should be split to preserve the integrity of both questions for others who may read/search here on forums. 

Oh and Rob also!!

This thread has been hijacked from its original question of TechNet benefits.

 

It has gotten so convoluted that I don’t see a way to split off Mike’s questions and replies.

 

Mike, if you still have questions about what you have been asking, then you should start your own topic in the appropriate category.

 

Any more replies to this Thread should be back on Topic.

 

Thank you for your cooperation. 

 

Lee

I am pleased that I made it sufficiently convoluted that Lee cannot figure out a way to split it off.    My work here is done. 

Hey, we all can get off topic sometimes.  I wouldn't have mentioned it if I thought it were difficult to split them.   But since there is almost a 50/50 split in posts on each topic now (and 3 pages), I can understand the difficulty.  No worries, I'm sure.

I am pleased that I made it sufficiently convoluted that Lee cannot figure out a way to split it off.    My work here is done. 

ROTFLMAO.

 

Thanks for my day brightener Mike.

 

Lee

By joining TechNet you undertake to follow the explicit NDA that comes with it.  So the only way to find out is by joining.

 

Okay, let me ask the question again in a way that will not violate anyone's NDA.

 

If I pay the $99 to purchase the (FileMaker Developer Subscription) because I want to see "an early view of unreleased software" am I going to be disappointed?

 

Also...if I join am I going to be shown the FileMaker Developer super-secret handshake?

I've had a subscription membership for over a year and have yet to see any  pre-release software.

I've had a subscription membership for over a year and have yet to see any  pre-release software.

 

Thanks Rick, that's kind of what I suspected.

Remember nobody is allowed (by NDA) to tell you if and when that changes.

See screenshot - not sure how much more clear it can be...

 

 

Pre-release software means that is basically ready to ship. So you get a relatively short time frame to pre-view it before it is announced and shipped.

 

What do you see if you go to this page: https://community.filemaker.com/apps/technet

I've had a subscription membership for over a year and have yet to see any  pre-release software.

 

Since the release cycle is roughly every 18 months, not 12 months, that's about what you'd expect.