>Just some notes I made when reading through this:
>

>http://www.visual-freepro.org/wiki/index.php/VXB%2B%2B
>LOCAL PERSIST
>	I'm assuming these vars are still scoped to the function. Would also expect them to be 
>	scoped to the class instance if the function is a method of the class. Big potential
>	for memory leaks if in a class; would definitely expect these to be garbage collected
>	when the class goes out of scope.

They are first persistent to their scope, which means either to the thread or globally, then to their instance. Visual FreePro handles all memory allocation and de-allocation as instances come in and out. They are garbage collected immediately when an object goes out of scope.

>XIF..XELSEIF
>	So does this do an AND and not an OR? Do they short-circuit?

They are AND to the preceding IF and ELSEIF. Their purpose is to allow code to fire between tests in a very easy to visualize way. There are commands (XFALLTHROUGH, XGOTO, and XRETRY) which allow flow-control from within the IF or XIF, or ELSEIF or XELSEIF clauses to handle explicit flow control. As it is, control will enter the IF, process through any XIFs at that level, and then that block will be entered. When it hits the next ELSEIF, ELSE, or ENDIF, it will exit. If it fails any test it will to go the next ELSEIF block if any, or ELSE if it exists, or exit. Any code previously executed in an IF..XIF or ELSEIF..XELSEIF sequence will have been executed, even if ultimately the test fails.

>ALWAYS BEFORE and ALWAYS AFTER on DO CASE and SWITCH
>	Not sure why this is needed. Seems you can get the behavior you want just by putting code before/after the DO CASE.
>	Guess this would be used in cases where you RETURN from one of the CASE statements? If so, when does the ALWAYS AFTER
>	fire?

Each ALWAYS BEFORE and ALWAYS AFTER can have a named scope, or a logic scope. It allows certain code to be run if and only if a case condition is entered, before that case code is executed, and the same when exiting. If an explicit RETURN is executed in the CASE code, it will override the ALWAYS AFTER. If it needs to return, it would be better to raise a flag, exit the CASE, and then test the flag and return there.

>Explicit Multi-Threading
>	What happens to the current datasession scoping in the new thread? Assuming it respects the
>	current datasession setting (private vs default) so it wouldn't be visible?
>	Would be REALLY nice to pass current datasession and/or a table as a parameter to a function.

Datasessions are objects. They can be passed. Datasession 1 is global, all others are specified when created as to their scope, which is global, thread, or scoped (private on form, part of a callback, for example).

>http://www.visual-freepro.org/wiki/index.php/VFrP_changes
>	Properties
>		BindControls
>			Not sure how you are going to support the main reason for this property - you have
>			bound to a field in a table/cursor but that table/cursor isn't immediately available.
>			Are "invalid" bindings just ignored until the time that they might be valid?

Yes. If something is no longer in scope, it will appear grayed out with the prior data which was valid remaining until it comes back into scope.

>		Comment
>			You mention all forms are modeless. How do you handle code where you want the code to be
>			blocked until the user returns from some form?

There is a mechanism provided to specify "modal input," which allows system focus to hone in on a particular form. However, because Visual FreePro is multi-threaded, this cannot be modal in the strictly modal sense. There are certain cases where the multi-threaded nature of the engine must introduce popups which will override the modal nature, and these will still appear.

Visual FreePro does introduce a "user awareness" concept with its input, meaning that if you are about to touch the screen where an "okay" button exists, and then suddenly a new window pops up and has a different button (perhaps one you did not want to press) right where your finger would land, it is smart enough to recognize that such is not a valid input and will ignore it for a period of time after instantiation if there was a prior input already active.

The modal mechanism in most cases will allow the system to appear modal, but it is not a form-level setting, but rather a "VM Instance" level setting, which is scoped onto a particular input, which can be a form.

>		HWnd
>			Not getting a real HWnd kind of defeats the purpose of this, no?

Visual FreePro supports OpenGL for forms, and it is targeted not only for Windows, but also for Linux, FreeBSD and Android.

The data which is on the window is drawn from buffers which exist in other places. Using the OSARBITER function you can create windows in Windows which are message-only windows, to allow you to receive messages, if need be, etc. However, through the Visual FreePro graphics object, all content which appears on a form, or on any form component, is available to be extracted in bitmap form to another source (memory, disk, etc.).

>Misc
>	Is there going to be the ability to migrate an existing VFP app into VFrP? If so, some of the
>	things removed may require a lot of code changes.

Yes. Visual FreePro introduces also the ON COMPATIBILITY feature which will identify things which no longer work the same way they did in Visual FoxPro, allowing a code block to be called (similar to how ON ERROR handles an error) to identify he incompatibility, and the proposed workaround.

Thank you for your extensive commentary, Paul.