Just wondering where the development is up to compared to the roadmap? I just ran my first app through the adaptation assistant and I have a lot of forms that use formsets, these are really old having gone through the converter from Foxpro for Windows way, way back, which in turn came from Foxpro for DOS, so you can tell how old some of the code is, but hey, it still works. Also, there are combo boxes with queries as a datasource. Currently formsets are not supported and only type 5 datasources in combo boxes. According to the roadmap on the site these were due for inclusion in November and January respectively. So I'm guessing that things have got a bit delayed. Can you give us an update on the current timetable?

Also, I noticed in the grid of uploaded stats that some of the entries are marked as version 2 or 3. I thought I had the latest version but mine's only v1. Have some people got beta versions of upcoming releases?

Many Thanks

Malcolm

You are just right - until now our roadmap was 'tentative' and not really based on user feedback and resource constraints.
We are in the process of correcting that, based on the results of http://foxincloud.com/surveys.php?2, and project shared data.
We'll soon publish a dynamic roadmap based on the "FoxInCloud-Version.xls" workbook we distribute with FAS (attached to download mail and installed into <VFP9>\tools\ab\).
FAA will integrate this roadmap so that user may instantly know when a given feature is scheduled to be available.

Roadmap will also be dynamic in the sense that, if a given feature is a must-have for a given application having a large enough concurrent user count, we'll move it up into the roadmap.

Please note that you can expose your app progressively to the web, e.g. some forms first, then expand to another set of form and so on...

So far, only combo/listboxes with a Dynamic list need be redefined to .RowSourceType = 5. Dynamic means that the contents of .List may change during the course of a user event, or during form.Init(); a typical use case is dynamic filtering, when contents of a child list depends on a user selection in parent list (e.g. country > cities).
You don't need to change static lists.
That is why FAA only gives a warning, as most lists in a typical VFP application are static, IOW filled once for all at their .Init()

'Version' in http://foxincloud.com/shared-projects.php means the number of times that the Analysis results of a given project have been shared on FoxInCloud.com; probably not an appropriate term, any suggested alternative welcome ...

HTH,
thn

Thanks. if you are taking requests, I would like these moved up earlier:

For controls with Disabled* properties (e.g. Commandbutton), create a .disabled CSS class instead of changing HTML element's style properties

PageFrame page tabs, extensible display:
- Default styles in CSS file instead of in-line as of now
- Add default CSS class(es) are based on page class hierarchy, + 'tab'
- Add dynamic tab CSS classes: 'disabled' when page is disabled, 'hover' when hovered, 'active' when tab belongs to activePage

Provide a set of standard FoxInCloud CSS style sheets to easily upgrade web application's look and feel

Support form.Visible

Support awPag.Deactivate() when awPgf.ActivePage changes

Event 'Resize' is supported on server

And this is scheduled next, just want to state it is a big item in case you wanted to mve it kater:

Support all Locale ID, code page, and FontCharSet supported by VFP

Thanks for this feedback.

Could you add some details on which version / release you would need this features? Please take into account your own development / adaptation schedule.

Please note we'll revise roadmap no more than once a month, and version under development may not be impacted, except for very minor changes.

As we need to make sure roadmap fits the schedule of a majority of FiC developers, and never breaks any prior commitment to a client, we'll somehow poll developers on what can be done.

We'll release a roadmap revision policy soon.

HTH,

The multiple langauge is something users are waiting for that we mistakenly promised.

The disabled controls are urgent because we changed many enabled appearances for texboxs etc and we have not been able to reliably use the ::enabled or::disabled. If we could use those better this would be a less priority.

The pageframe tabs is also something we mistaklenly promised.

After that the page deactivate is something we work around now, but would be easier if we did not have to.

form.visible will allow us to do things in the specs from the client we cannot do now, and resize is something we would use but no users are screaming for.