>Hi Sergio:
>
>There must have been something else gonne wrong,
>I use the same code almost on a daily bases and NEVER had any problem.
>
>It does preserves papersize and orientation while cleans up the rest.
>Now for everything to work properly, FRX have to be correct at first place.
>Paper size/orientation have to be there.
>
>So please make test with some report;
>
>Create new report with wizard, set up paper size & orientation properly then close report
>and then clean it up with function provided in XDIR.
>Pls let me know what is remaining afterwards in those rpt fields.
>
>You are right
>
>I APOLOGIZE
>
>My problem is the paper size so I changed your code a litle and I made a mistake so all features were cleaned Orientation included.
>

C'mon Hector, no need apologising :)

Now the rest of the problem is kind of common I wld say, when you ship application to the various users.
People do use different paper sizes, so solution in this case could be to populate multiple versions of the basically the
same FRX reports and then let users switch them according to printer/paper they are using.
You might wanna experiment and try switching paper size on the fly via (amended) function but I never really liked this
idea od messing up with FRX at user site. (Function in XDIR is suitable for precompile process or project hook)

Instead, I used to have data driven aproach to solve this problem, which included registering user printers, FRX layouts etc and then switching them according to some setup stored in tables. All wrapped in class object. It is a bit more complicated but offers more power. Can't share that (old) code unfortunately.

Of course you will know better what is best for you, this is just few ideas. :)

Sergio