1. I've said this before in another post, but just to keep the point alive: would be really nice to have C# equivelant code where-ever VB.NET code is shown in the documentation.  This makes it much easier to get a handle on the development, since you can just copy and paste code as you are learning the system rather than hand-typing and generating all kinds of dumb typos...

2. Tutorials could use a bit more sprucing up.  For example, it is assumed that a person following the tutorial follows certain naming convention (e.g., txtMyField or cmdMyButton).  I'm used to this from my VFP background, but brand new users may find it a bit hard to follow the tutorials when they name controls something else than is expected, and then the compiler throws all kinds of errors.

3. Would be nice to have a complete class library reference addendum in the end of the documentation.  This way users could quickly look up and learn about any and all SF controls.

That's it for starters.  Maybe others want to pipe in here.  I think the documentation over all is quite good, but it would certainly benefit from a few additional features. 

Speaking of which, do the training videos morph with the program as new things are added and old things changed?  If one buys the video(s), does one get free/discounted updates as the videos are updated to reflect the current state of affairs?

Thanks!

Pertti

As I mentioned in your previous post...we are working on the docs all of the time and we are working on this.  Thanks for your input.

I am sorry, but I am not seeing your point here.  We could have named the controls MyTextBox or YourTextBox...the name is not important.  We had to assign a name for the tutorials and so we used a very common naming convention...but even if you had not chosen to do so, this would have not caused you any harm as long as you reference the correct object...that is one of the nice things about strong-typing...if you do not reference the proper name you get a compiler error.  I guess my point is that it doesn't matter what the names were...if you reference the wrong name, you get a compiler error.

We actually have had this in the past and will post it again in the future...we have been dealing with an issue with a 3rd party vendor on compiling this help file and once this issue is resolve we will make it avaialble again.  You are right though...this is a nice tool and we will try to make it available again very soon.

Thanks...we have a continuous motion going with our documentation.  So this will continue to grow....as will the samples.

This is a 3rd party company and are not done within MicroFour...however, I know that they work very diligently to keep their product moving forward as well.

I can't help you here...you will have to contact them (www.stratatrain.com )

A couple of comments regarding documentation:



Concerning control names: in consideration of those who are really new, you might just have a comment at the top that indicates they need to pay attention to the name of the controls or they will get compile errors.



Controls: I'd like to see more info on the controls you provide, both for windows and the web.



Other goodies: I've noticed there are screen capture tools and other tools. It would be nice to document these also, including examples, both code and even more important, usage ideas.

Greg:

That's my point about control naming, too.  For example, in one tutorial we are adding buttons and text boxes without explicitly naming them, then in the BO we are referencing them as cmdSearch_Click... etc., which, if you haven't paid attention to the naming and can't decipher the error message generated will stop you in your tracks.  Not a "huge biggie", really, it just generates tech support calls/emails and unnecessary gray hairs and frustration for potential customers.  In my experience especially with tutorials you can never be too explicit, because if an evaluator gets stuck in a tutorial, he/she might just walk away from the entire product, for better or for worse...  The thinking goes something like this: "If I can not get through the @#$%%$ tutorial without a problem, I wonder how many problems I might have working with the actual framework." 

I bet that if/when StrataFrame gets their detailed class library documentation worked out it will help a great deal understanding the moving parts in each class/control.

Pertti