Tore, thanks for stepping in. Can you give me an example how to code features only for web or desktop? I am still struggling with the idea to have either a separate code base for Desktop and Web, or to try putting it together in one.

The first option (separate for Desktop) would enable me to reuse my existing framework without adaptations.

For the fun of it I ran Payroll Pro on the Adaption Assistant and it came up with over 5000 manual adaptations.


>Hi Thierry and Christian,
>
>since I know Christian from working with him, and I have also gone through a FiC conversion "workshop" with Thierry and Tuvia a while back, I can confirm Thierry's words.
>
>It's really easy to "adapt" your program for the web. And it's also very easy, with only one code base, to make what seemingly is two versions, one for the web and one for workstations. If necessary, you can add features which are only available on the web, and you can add features which are only available on workstations. It's really just a matter of adding a If-Endif block.
>
>>Hi Christian,
>>
>>You can use FoxInCloud on any VFP app, either existing or new (FoxInCloud users split almost evenly into these 2 cases).
>>
>>In fact both cases are the same; you can:
>>

>>
1. develop your new app. to the expected functionality,
   >>
2. validate with your client on the desktop,
   >>
3. adapt to the web using FoxInCloud Adaptation Assistant,
   >>
4. setup a test server that your client can access,
   >>
5. validate with your client
   >>
6. setup a production server
   >>

>>and you're done.
>>
>>Reminder: the application works exactly the same on the desktop before and after adaptation.
>>
>>There indeed is a difference in handling the later evolutions: you can either repeat the above procedure or code directly the 'FoxInCloud way' that you will have learnt through your inital adaptation experience. Main stuff to remember is:
>>

>>
• use classes derived from FoxInCloud 'base classes' (aw.vcx)
  >>
• add this code at the beginning of any event method:
  >>

  >>if thisForm.wlHTMLgen
  >>  return
  >>endif
  >>

  >>
• call forms and system dialogs (such as MessageBox) using FoxInCloud methods(http://foxincloud.com/tutotest/bs/Modal.tuto):
  >>

  >>[thisForm.]wForm('form[.scx]', <modal or callback>, parm1, parm2, etc.)
  >>[thisForm.]wMessageBox([<callback>,] eMessageText [, nDialogBoxType ][, cTitleBarText][, nTimeout])
  >>etc.
  >>

  >>
• move modal response processing code to a call-back method (http://foxincloud.com/tutotest/bs/Modal.tuto)
  >>
• etc. (see all adaptations on http://foxincloud.com/tutotest/bs/)
  >>

>>
>>You have multiple ways to learn FoxInCloud: documentation, videos, demo app, free support on public forums.
>>
>>
>>>Thanks for posting this article, it is a very interesting read.
>>>
>>>I have a special case: A client needs a relatively simple system to register information. There are of course a few details involved, but there is no real complex calculation or business requirement. However the system needs to grow in size by adding more modules and possibilities.
>>>
>>>What is important is, that there must be some user interfaces available as browser based UI, but the administration and reporting can be done with a classic Client/Server Desktop app. There are no special requirements in regards to which developing technologies to use.
>>>
>>>So my thought was to do a kind of hybrid application, using our VFP framework for the database administration and security setup etc, and to develop the front end UI interfaces in HTML/JavaScript etc. So I am thinking, since the core application is VFP, it would make sense to use FoxInCloud to create the Webbrowser presentation. As I understand it, I could use VFP to create those interfaces and FoxInCloud gives me the possibility to create the HTML pages?
>>>
>>>My question now is: is this a sensible way, or should FoxInCloud only be used for already existing VFP applications?
>>>My second question would be, can I use one VFP application and then port only some of the forms to the FoxInCloud app? Or do I need to separate the code already in advance.