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.
Share your findings with eXpress++ and Xbase++
Re: Share your findings with eXpress++ and Xbase++
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.
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.
Re: Share your findings with eXpress++ and Xbase++
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.Roger said at a conference, 30,000+ lines of code in one PRG is a big NO NO.
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.
Re: Share your findings with eXpress++ and Xbase++
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
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