On Sun, 21 Mar 2010, Szak�ts Viktor wrote: Hi,
> > But it's not Clipper compatible. Clipper does not support > > <alias> -> &( <exp> ) > > in macro compiler. Anyhow we can add such extension. > > It's enough to add 1 line macro.y. > > We already added many extensions to our macrocompiler eliminating > > Clipper macrocompiler limits which do not exist in compiler. As long > > as such differences between compiler and macrocompiler are not results > > of some other conditions then they are semi bugs for me. > > So if no one has sth against then I'll commit modification which > > enable support for above syntax. > If it doesn't have any bad side effects, it's IMO okay. I do not see any. > BTW, maybe it would be also useful to add > HB_FIELDPUT()/HB_FIELDGET() which would also > accept field _name_ as parameter. Interesting proposition though it will make the same job as FIELDGET( FIELDPOS( <name> ) ) / FIELDPUT( FIELDPOS( <name> ), <xVal> ) so I do not know if it's really necessary. Anyhow if table has field names which are not valid Clipper identifiers then accessing by name with above functions is the only one method to get/set field value so we should rather think about efficient method to access such fields in expressions, i.e. we can add support for FIELD->'<fieldName>' FIELD->'FIRST NAME' := "Phil" We can also use functions like proposed by you HB_FIELDPUT()/HB_FIELDGET() but in such case they should generate RTE on wrong field names and of course functions are not such flexible as native syntax. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
