Share your findings with eXpress++ and Xbase++

If you are converting a text-based Clipper application, a FoxPro application or just writing an application from scratch, use this forum for your eXpress++ questions.
Post Reply
Message
Author
User avatar
alepap
Posts: 94
Joined: Tue Jul 28, 2015 5:15 am

Share your findings with eXpress++ and Xbase++

#1 Post by alepap »

I have discovered eXpress++ 2 years ago and been really playing and adding stuff to a large application since a few months. There is a lot of interesting stuff in that eXpress++.

So I encourage people to use this section to share things that you find interesting with a few lines of codes that other people could try.

User avatar
alepap
Posts: 94
Joined: Tue Jul 28, 2015 5:15 am

Re: Share your findings with eXpress++ and Xbase++

#2 Post by alepap »

Xbase++ offers pbuild to create your project. I was using SET PROCEDURE before that and PBUILD is amazing.
You set all your PRG LIB and the compilation is a lot faster. It only recompiles the PRG changed.

Roger said at a conference, 30,000+ lines of code in one PRG is a big NO NO.

It makes a big difference when you do a few modules, place the functions inside of the correct module, make small functions and try not to repeat same code.

The way to compile now, using GUI, using eXpress++, is with PBUILD.

This is how you can get the CRT class and GUI used with eXpress++

Once you have this, you can start using some graphic dialogs in your application. It already it starts to look good.

User avatar
rdonnay
Site Admin
Posts: 4804
Joined: Wed Jan 27, 2010 6:58 pm
Location: Boise, Idaho USA
Contact:

Re: Share your findings with eXpress++ and Xbase++

#3 Post by rdonnay »

Roger said at a conference, 30,000+ lines of code in one PRG is a big NO NO.
The reason I suggest this is because code that contain hundreds of pre-processed commands, like those in eXpress++, takes longer to compile and that compile-time increases exponentially with the number of commands in the source file.

I rarely see this in eXpress++ applications, but occasionally I notice that a customers' application .PRG takes a much longer time to compile, i.e. several seconds.

The 30,000 lines of code is not the real issue. Instead, it is the number of commands in a source file that will affect compile time performance. Look at the below case study. I created 6 different programs. Test100.Prg contains 100 @ .. DCPUSHBUTTON commands, whereas Test3200.Prg contains 3200 @ .. DCPUSHBUTTON commands. The .EXE sizes increased proportionally to the number of commands, but the compile time increased exponentially, especially when the number of commands exceeds 500.

Code: Select all

TEST100.EXE created successfully.
Processing time:      0.43 secs.

TEST200.EXE created successfully.
Processing time:      0.69 secs.

TEST400.EXE created successfully.
Processing time:      1.28 secs.

TEST800.EXE created successfully.
Processing time:      2.74 secs.

TEST1600.EXE created successfully.
Processing time:      7.65 secs.

TEST3200.EXE created successfully.
Processing time:     30.34 secs.
The eXpress train is coming - and it has more cars.

User avatar
alepap
Posts: 94
Joined: Tue Jul 28, 2015 5:15 am

Re: Share your findings with eXpress++ and Xbase++

#4 Post by alepap »

If you need to know what files (DBF) are locked on a network or local machine, this nice little tools shows all DBF files that are locked.

It´s called Process Explorer
It´s from Microsoft, FREE part of Windows sysinternals
https://technet.microsoft.com/en-us/sys ... lorer.aspx

Download
Place in a folder
Run it
Goto Find
Find Handle or DLL
Type dbf
Search

Bingo,you get all DBF files that are locked

Post Reply