bc9Basic PowerBASIC Address port

[James C. Fuller]

Ok, I guess this is my final version of the PowerBASIC PBWin Address port to bc9Basic.
The basis was to keep it as close to the original as possible. To this endeavor I decided to use resource dialogs for both the main window and the Find pop-up. I often used aplib to compress static data (strings,Spread Format Data) with PowerBASIC in my commercial work of years past. The compressed data was then added to the app's resource file as RC_DATA. I chose to do this with the data for the Country combo.
The bc9Basic translated c++ code  was compiled with the Visual Studio 2015 Community c++ compiler using a modified version of Fred Harris's TCLib.
It also makes heavy use of Fred's String class.
It has been discussed elsewhere about the overall design of the original being far from what one would use for a real-world application.
I did deviate a bit on Add/Update, and by adding a Save option to the menu.
Nothing is saved on an Add/Update operation, only the array data is changed.
On a save the original/current CardFile50.bin will be renamed adding the date and time and a new Cardfile50.bin will be created with the new/updated data.
I added a status bar where Search info is posted.
You will need a updated bc9Basic translator for use with this project.
https://sourceforge.net/projects/bc9basic/files/bc9Basic/bc9_9258.zip/download

The attached zip may be placed in either the bc9Adp2 or bc9Afx projects folder.
It includes the bas, cpp, and exe files so you do not need the above packages to run or view.

Final exe file size: 29,184 bytes

James

[Frederick J. Harris]

Good job Jim!  I think that's really good being as its a significant sized app with a good many lines of code.  Its been awhile since I looked at it but I recall there was something wrong with the ability of the PowerBASIC original to save new entries or something like that.  Or maybe it was persisting changes to existing entries.  Anyway, I recall fixing that in the PowerBASIC versions I posted.

My only other thoughts on that app since we were all working on it a year or two ago was that to do it SDK style we were all (or at least me) laboring under the assumption that the SDK version had to use the same fonts and sizes of everything as the DDT Dialog based version.  For doing it SDK style with CreateWindowEx() instead of the Dialog calls one had to do an excessive amount of calls to font creation and font alteration functions (CreateFont() / SendMessage(..., WM_SETFONT,...)) to make an example indistinguisable from the Dialog based version.  That seemed to me unfair somehow, in that it forced the SDK version to jump through hoops that the Dialog based version didn't have to.  If I were to do that again (maybe when I retire), I think I'd give a whirl at it just with the standard fonts and sizes SDK calls give me which originate from stock system settings I guess.