FoxPro

[appinformatica]

Commands like @ say / get / read / ??? will be implemented?

Using DBF with CDX like:

INDEX ON TMCOD+ARCOD1 TAG ANARTI01 OF (USE_NAME) FOR !DELETED()
INDEX ON TMCOD+ARCOD2 TAG ANARTI02 OF (USE_NAME) FOR !EMPTY(ARCOD2).AND.!DELETED()
INDEX ON TMCOD+UPPER(ARDES+ARDES1)+AR_ARMAIN+ARCOD1 TAG ANARTI_S OF (USE_NAME)
INDEX ON TMCOD+TGCOD+TGCODS+ARK01+ARK02+ARK03+ARK04+ARK05+A RK06+ARK07+ARCOD1 TAG ANARTI04 OF (USE_NAME)
INDEX ON TMCOD+TSCOD+AR_LINEA+TGCOD+TGCODS+ARK01+ARK02+ARK0 3+ARK04+ARK05+ARK06+ARK07+UPPER(ARDES) TAG ANARTI05 OF (USE_NAME)
INDEX ON TMCOD+AR_ARMAIN+AR_ARMISU+AR_ARCOLO TAG ANARTI06 OF (USE_NAME) FOR !EMPTY(AR_ARMAIN)
INDEX ON TMCOD+UPPER(ARDES)+TSCOD+AR_ARMISU+ARK01+ARK02+ARK 03+ARK04+ARK05+ARK06+ARK07 TAG ANARTI07 OF (USE_NAME) FOR !EMPTY(TSCOD).AND.EMPTY(AR_ARMISU)
INDEX ON TMCOD+TSCOD+AR_LINEA+AR_ORDSTA+TGCOD+TGCODS+ARK01+ ARK02+ARK03+ARK04+ARK05+ARCOD1 TAG ANARTI08 OF (USE_NAME)
INDEX ON TMCOD+TSCOD+TGCOD+AR_ORDSTA+TGCODS+ARK01+ARK02+ARK 03+ARK04+ARK05+ARCOD1 TAG ANARTI09 OF (USE_NAME)
INDEX ON TMCOD+DTOS(AR_DATVAR)+TSCOD+AR_ORDSTA+TGCOD+TGCODS TAG ANARTI10 OF (USE_NAME)
INDEX ON TMCOD+ARFOR+TSCOD+AR_LINEA+AR_ORDSTA+TGCOD+TGCODS+ ARK01+ARK02+ARK03+ARK04+ARK05+ARCOD1 TAG ANARTI11 OF (USE_NAME)
INDEX ON TMCOD+AR_ARMAIN TAG ANARTI12 OF (USE_NAME) FOR !EMPTY(AR_ARMAIN)
INDEX ON TMCOD+AR_TRSEQ TAG ANARTI13 OF (USE_NAME) FOR !EMPTY(AR_TRSEQ)
INDEX ON TMCOD+IIF(EMPTY(AR_ARMAIN),ARCOD1,AR_ARMAIN) TAG ANARTI14 OF (USE_NAME)
INDEX ON TMCOD+AR_TRSEQ2 TAG ANARTI15 OF (USE_NAME) FOR !EMPTY(AR_TRSEQ+AR_TRSEQ2)
INDEX ON TMCOD+AR_ARMAIN+AR_ORDSTA+AR_ARMISU+AR_ARCOLO TAG ANARTI16 OF (USE_NAME) FOR !EMPTY(AR_ARMAIN)

creates problems.
Solutions?

[lianjasupport]

What problems are you referring to? These index commands are already supported.

No @say/get will not be supported. That is old foxpro syntax not vfp.

[appinformatica]

The error is:

USE DB_NAME
REINDEX

dom 1. lug 10:32:53 2012
**** Lianja Recital error ****
Fatal I/O error reading index file - errno -248 (ERROR - invalid tag handle)


For supported commands i must refer to help on the right of the console page?

Thanks

Massimo

[lianjasupport]

Have you imported this into Lianja from vfp? If not, do so. Lianja handles 64-bit files so you need to import your 32-bit vfp tables.

[lianjasupport]

You can find all commands supported in the help workspace.

[pcelba]

=No @say/get will not be supported. That is old foxpro syntax not vfp.

Many programs running under VFP are still using say/get syntax... And Lianja is also positioned as Recital replacement which supports say/get. Or am I wrong? Does your post mean old Recital and FoxPro programs must be redesigned from the scratch?

[lianjasupport]

Although Lianja does parse these old constructs we do not recommend nor officially support them as its is very old deprecated syntax in VFP that does not really fit into the Lianja architecture and vision for desktop, cloud and mobile Apps.

Lianja is not positioned as a Recital replacement. They are two separate technologies that focus on different things entirely.

Recital is a character mode and batch data-centric scripting language, and can be used for applications that require this functionality. It is commonly used in systems that require high speed data entry and/or concurrent background batch job execution.

Lianja is a completely different technology which targets GUI desktop, cloud and mobile UIs. If you watch the video tutorials you will better understand the methodology behind building Apps in Lianja.

The choice of VFP as one of the scripting languages supported was due to its good data centric capabilities, it's object-oriented capabilities and it's core UI classes. Lianja also supports Python, PHP and JavaScript which can be used with these core UI classes which are in fact a subset of the UI classes and framework available in Lianja.

Lianja will allow you to use your existing VFP knowledge and if you follow best practices re-architect old-style Apps into Apps with a more modern and attractive UI providing your customers with a nicer user experience coupled with the advantage of being platform and UI device independent.

In order to achieve this, you may have to take a different view from your old ways of the past but the advantages far outweigh the disadvantages.

With close to 4000 beta downloads now and growing on a daily basis, every developer has different things that they consider important. Being a community driven development, we do listen, and through enhancement requests we make decisions on what functionality we include in the product. This functionality is prioritized based on developer feedback, and how well it fits into the overall Lianja vision.

Getting involved in the Lianja Development Community as you are now and interacting with other developers is appreciated as is your feedback.

[siotti]

Although Lianja does parse these old constructs we do not recommend nor officially support them as its is very old deprecated syntax in VFP that does not really fit into the Lianja architecture and vision for desktop, cloud and mobile Apps.

Lianja is not positioned as a Recital replacement. They are two separate technologies that focus on different things entirely.

Recital is a character mode and batch data-centric scripting language, and can be used for applications that require this functionality. It is commonly used in systems that require high speed data entry and/or concurrent background batch job execution.

Lianja is a completely different technology which targets GUI desktop, cloud and mobile UIs. If you watch the video tutorials you will better understand the methodology behind building Apps in Lianja.

The choice of VFP as one of the scripting languages supported was due to its good data centric capabilities, it's object-oriented capabilities and it's core UI classes. Lianja also supports Python, PHP and JavaScript which can be used with these core UI classes which are in fact a subset of the UI classes and framework available in Lianja.

Lianja will allow you to use your existing VFP knowledge and if you follow best practices re-architect old-style Apps into Apps with a more modern and attractive UI providing your customers with a nicer user experience coupled with the advantage of being platform and UI device independent.

In order to achieve this, you may have to take a different view from your old ways of the past but the advantages far outweigh the disadvantages.

With close to 4000 beta downloads now and growing on a daily basis, every developer has different things that they consider important. Being a community driven development, we do listen, and through enhancement requests we make decisions on what functionality we include in the product. This functionality is prioritized based on developer feedback, and how well it fits into the overall Lianja vision.

Getting involved in the Lianja Development Community as you are now and interacting with other developers is appreciated as is your feedback.

I understand your plans and vision. But one question: The roadmap for beta 7 says that .spr files are supported. Since we still have a lot of .spr files generated with FPW 2.6 we tried to run them in Lianja, but it failed. In VFP we can run this programs without any problem.

So what kind of .spr files you thought that should be supported with beta 7?

[lianjasupport]

I believe this was answered a while back. We decided against supporting .spr files. During the beta there has been many features and functionality added and a few removed as development progressed.

[lazyfox]

I can sympathize with refactoring the roadmap to reflect user wishes and newer methodologies.
That said - just from reading through the roadmap I was under the impression that spr/say-get would be supported,
as I don't see in the roadmap where it is postponed or dismissed.
Such omissions from previous targets must get documented in the roadmap,
otherwise you might get angry or at least miffed customers who relied on the outdated information.

Also VFP3 added a few new options - AFAIR a way to name the element and a way to set the class of the control,
giving old say/get screens more than a touch of new OOP options, for instance by replacing the controls
with one of your own subclasses giving it new PEM's and added behaviour like self-setting fonts or colors
to schemata based on validation rules and/or results (must enter/wrong input) of the more current apps.

When upgrading a couple of very large insurance apps this was the key to hook new common functionality
from current development into the old-sytle screens, which were kept for these existing apps.
For me not a first order priority, but perhaps an idea to be looked at again if a customer buying a couple of licenses
needs to utilize this - a one man shop probably won't have apps of a size where keeping a couple of hundred
complex say/get screens makes a difference. But look up the enhanced syntax if you implement:
this was AFAIR documented only in the very first versions of vfp in detail, later say/get was glossed over.

It saved the customer a not too shabby 6-figure sum in porting to vfp6 on a project well into 8 digits cost -
as the whole enchilada of newly written specs, screeen creation and testing was largely sidestepped.
And yes - I do realize that other ways to port such spr-forms can be generated, from introspecting a running
vfp-spr form to modifying the source code for the screen transporter available in vfp ;-)