.w compilation ok with prowin32.exe fail with _progres.exe

[grunnpi]

Hello there !

I have to source code, containing FRAME definition, that currently compile fine using "prowin32.exe".
I'm trying to compile with "_progres.exe" in order to produce some 64 bit .r code.

But, I've got some error as following :
ERROR ! **COMBO-BOX group-account will not fit in FRAME DLG- in PROGRAM


My guess is that it's related to "progress.ini" file, that contain :
[Startup]
DefaultFont=MS Sans Serif, size=8

And most of our hundreds FRAME use DefaultFont, that produce on Windows 32b some screen that doesnt fit compiling with _progres that is mean to be character screen.

But I must compile same source code, that can be some persistently loaded librarie under appserver (unix/64b side) while same source can be run as screen under windows (win/32 side).

Any clue ?

Thanks in advance for your help !
Have a good day.

Grunnpi.

 

[TomBascom]

App server code shouldn't have frames in it. So your compile error is doing you a favor.

 

[grunnpi]

You're right Tom, Appserver musn't have FRAME.
Thank you for responding.


But, our code is, for exemple :
myLib.p
> PROCEDURE pDisplaySomeFrame.
> PROCEDURE pDoSomeBatch.

On prowin32.exe
RUN pDisplaySomeFrame ON mh-myLib-persistent.

On _progres.exe
RUN pDoSomeBatchON mh-myLib-persistent.

Meaning, I don't run any frame on Appserver, but I need .r code to be available.

(Legacy code is very heavy in our application, meaning updating it would cost too much for now... I'm looking for other solution)


Thanks for any other clue.

 

[LarryD]

Maybe I'm wrong, but can't you use a preprocessor directive ?

e.g.

&IF OPSYS = "WIN32" &THEN
PROCEDURE pDisplaySomeFrame.
... frame stuff ...
END PROCEDURE.
&ENDIF

 

[TomBascom]

Perhaps I do not understand.

Although they are quite similar in capabilities _progres <> app server. The character client is perfectly capable of having frames. But you stated that the problem code was app server code. App server code is a subset of what both prowin32 and _progres can compile. But if you compile code that has UI references using either _progres or prowin32 the app server won't be able to run it.

Are you trying to have a single set of r-code that compiles and runs on all of prowin32, _progres and _proapsv? That is not possible. There will be modules that are specific to each of those environments. Those modules must be handled separately.

 

[tamhas]

There seem to be a couple of things going on here. One of them has to do with programs with UI versus those without and the other has to do with 32 vs 64 bit. If you can move to 11.0, the same r code will run on 32 and 64, but until you get there, it won't. Code with UI still won't run on the AppServer, so even with 11.0 you have to pay attention to what goes where. In your OP, you are trying to get 64 bit code with UI. Given that the UI is for Windows, that is inherently 32 bit so you are mixing and matching here.

 

[grunnpi]

Tamhas, you're right : there are different points, I'll try to make it clearer.

We are migrating from 10.1b to 10.2b, and same time, want to use 32b r-code on Windows + 64b r-code on Unix side (cannot yet move to v11).
On the other hand, we have a huge application with thousands program that you don't want to upgrade each manually (as far as we can avoid it)

Previously, we were compiling in 32b r-code once, and run it every where.
Nows, as we want to use 64b on unix, we use a windows 64b server to compile our code.
Most of it gone well, except hundreds of programs that are defining some FRAME.

Probably most of them are screen only meant to be executed on Windows UI side.
But, with our lack of documentation/knowledge about legacy code, we guess some of these programs defined some "UI" part (run on Windows), but could also be used a business logic library on Unix side.

It was ok with same r-code every where (compiled only on windows prowin32 side) but now, doesnt compile anymore as we must use _progres.exe to build 64b r-code.

So, yes its not good practice to mix UI and Business logic in same code, but it cost lot to check & fix these stuff for now.
I was hoping some way to trick _progres, but according to all your response, I'm in trouble...

Any clue would be welcome. And if I'm still not clear enough, ask me more detail.

Anyway, thank you again all for responding.

Cheers,
Grunnpi.

 

[Stefan]

Previously, we were compiling in 32b r-code once, and run it every where.
Nows, as we want to use 64b on unix, we use a windows 64b server to compile our code.
Most of it gone well, except hundreds of programs that are defining some FRAME.

How were you compiling your 32-bit code? Were you using prowin32.exe and then simply deploying on Unix? If so, then nothing that is now complaining was actually run on the unix side, so you can 'safely' ignore all frame errors as belonging to code that is not run on Unix anyway.