MrBrown
Sep 6, 2006
Hello, I thought it was time I said more than that so here goes. I am not new to programming as such, but have been programming in non-window type applications for many years and since I have discovered Liberty Basic as a tool to get me into the world of Windows programming, I have come along a bit, mostly thanks to the participation of the all members at the forum.
I have shared two programs as freeware with the LB community, that being EMA (a defect manager application), and the other BraveKnight (a chess program). BraveKnight is still in progress and I will learn a lot from doing it to completion. EMA keeps a database in the DBASE format (DBF) via Cheetah .
I am looking for a DBASE recovery program, that is freeware, so if you know of one please share. I make backups of my data regularly though.
Update: I did not have much success in finding a recovery program and have gone for the backup route as standard procedure, although I do want to program a html record dump so depending on where one gets stuck in the database (using navigation controls), the program option will ask for the begin and end record number and generate the dump. Come to think of it a text dump with field delimiters might be better so there can be a seperate program to rebuild the database from there, still a html database dump will be nice for viewing. I will upload ema v2.5 before 20 May 2006 which will have a fuller help (well, actually there was none, snort, wheeze, chuckle) , a database to text file dump tool and a backup tool.
Not developing on BraveKnight currently though I mean to work on a move list and taking back moves when I get back to it.
--- update August 2006 ---
I have a idea about creating a more friendly file system that is instinctive and natural. Anyone who knows the PICK system of dynamic arrays will know what I am talking about. These systems will be in a library dll I am writing The principle of the system is that the data record is logically viewed as a record with 3 dimensions. Field Level, each field can have values and the values in turn can have subvalues. These values in a field can be linked to another field creating in effect an associated array. In real PICK there is a dictionary management tool which allows one to do queries and tie up structures, but I am just going to create the programming tools for reading and updating the data.The programmer will have to remember the file structure himself. Each record will be stored in a file directory as a file with no extension and will be given a record id as given by the user/programmer. To read a record the directory will be searched for the record id then read. (In PICK systems there is special file handling with record size limits, overflow handling, different file types depending on file keys etc, but this is too complex for my purpose as I am not writing a file OS, just a data manipulation tool). Manipulation of the record itself will be via functions calls to the dll's which will provide for inserting, deleting, updating and locating data. I am thinking of putting up this dll under the utilities section in lb downloads since I have no other place to store it. The dll will contain a lot of other functions unrelated to above, but which will be very useful. Going back to the former topic, there is nothing stopping the record from having more than 3 dimensions, but in practise I have found there is no need for anymore. And besides having the ability to actually create such records, using temporary records for internal data manipulation is bound to have advantages. Here is a quick example of what I am proposing.
PICK example (just for interest sake)
OPEN file to filevar else stop
read rec from filevar,"mykey" else rec = ""
rec<10> = "joebloggs"
write rec on filevar,"mykey"
My dll
open "mydll" for dll as #lib
calldll #lib,"READRECORD", "MyDataDIr" as ptr, "mykey" as ptr, result as long
rec = winstring(result)
calldll #lib,"UPDATERECORD", rec as ptr, 10 as long, "joebloggs" as ptr, result as long
rec = winstring(result)
calldll #lib,"WRITERECORD", "MyDataDir" as ptr, "mykey" as ptr, rec as ptr, result as long
---
Actually I will write more friendly wrappers for the calls to the dll's eg
rec = UpdateRecord(rec,10,'Joe Bloggs')
call WriteRec(Dir$,Id$)
---
The data record I will have to impose some sort of limit on, say about 50k for as yet, I don't know how to make the size unlimited (which in PICK is, although the OS writes the record over overflow sections and making the record bigger than what it was supposed to be is not recommend). Perhaps I can make a MEMO link in the record itself which is just a pointer to another record. Also the C dll will not really be needed, but I am writing it so for purposes of speed. Once testing and I find the speed overhead marginal then I will just publish the functions as LB code. Anyhow I have progressed someway so this will not be vapourware *grin*
--- Update - Still August 2006
Never had I suffered so much from string function programming *Errrk". I have been betrayed by two functions I wrote which I thought were solid, but were bug ridden. A strength of a chain is a strong as... Anyway, once I have DYNREPLACE, DYNLOCATE sorted out, I need to have DYNIS and DYNDEL newly coded (and DYNDELREC_ and then I will present my dll with documentation to the LB community. My dll is coded in BCX basic (and that version of basic is buggy, believe me) and I can present that as well for anyone interested. So in another week I will have it ready,. I suppose I should get a web page for myself. Gird your loins readers, this is going to tickle your pleasure spots. (Gird I said, hell, ungirdle rather)
Update : 3 september 2006
The first release isHere http://www.lbdownloads.com/files/viewtopic.php?p=307# |Here
6/9/2006
I used this exercise for practice and it just goes to show. Multiply IT projects projection time x impossibe.to.get.later.than.that x 2. Probably exaggerating. Hmm, my minds gone pleasantly blank and vacuous. I forgot what I was going to say. A software simulation of a 'hard array' (compiled) is probably the same thing,except a software simulation gives more scope, albeit it slower. I was thinking of writing a object orientated driver in basic, with baby steps for starters. Create a class and methods, create objects from them, let objects inherit from other classes, do a save state on that objects footprint. Teach that object new tricks through a language/action interface. Anyway, bye bye for now.
I have shared two programs as freeware with the LB community, that being EMA (a defect manager application), and the other BraveKnight (a chess program). BraveKnight is still in progress and I will learn a lot from doing it to completion. EMA keeps a database in the DBASE format (DBF) via Cheetah .
I am looking for a DBASE recovery program, that is freeware, so if you know of one please share. I make backups of my data regularly though.
Update: I did not have much success in finding a recovery program and have gone for the backup route as standard procedure, although I do want to program a html record dump so depending on where one gets stuck in the database (using navigation controls), the program option will ask for the begin and end record number and generate the dump. Come to think of it a text dump with field delimiters might be better so there can be a seperate program to rebuild the database from there, still a html database dump will be nice for viewing. I will upload ema v2.5 before 20 May 2006 which will have a fuller help (well, actually there was none, snort, wheeze, chuckle) , a database to text file dump tool and a backup tool.
Not developing on BraveKnight currently though I mean to work on a move list and taking back moves when I get back to it.
--- update August 2006 ---
I have a idea about creating a more friendly file system that is instinctive and natural. Anyone who knows the PICK system of dynamic arrays will know what I am talking about. These systems will be in a library dll I am writing The principle of the system is that the data record is logically viewed as a record with 3 dimensions. Field Level, each field can have values and the values in turn can have subvalues. These values in a field can be linked to another field creating in effect an associated array. In real PICK there is a dictionary management tool which allows one to do queries and tie up structures, but I am just going to create the programming tools for reading and updating the data.The programmer will have to remember the file structure himself. Each record will be stored in a file directory as a file with no extension and will be given a record id as given by the user/programmer. To read a record the directory will be searched for the record id then read. (In PICK systems there is special file handling with record size limits, overflow handling, different file types depending on file keys etc, but this is too complex for my purpose as I am not writing a file OS, just a data manipulation tool). Manipulation of the record itself will be via functions calls to the dll's which will provide for inserting, deleting, updating and locating data. I am thinking of putting up this dll under the utilities section in lb downloads since I have no other place to store it. The dll will contain a lot of other functions unrelated to above, but which will be very useful. Going back to the former topic, there is nothing stopping the record from having more than 3 dimensions, but in practise I have found there is no need for anymore. And besides having the ability to actually create such records, using temporary records for internal data manipulation is bound to have advantages. Here is a quick example of what I am proposing.
PICK example (just for interest sake)
OPEN file to filevar else stop
read rec from filevar,"mykey" else rec = ""
rec<10> = "joebloggs"
write rec on filevar,"mykey"
My dll
open "mydll" for dll as #lib
calldll #lib,"READRECORD", "MyDataDIr" as ptr, "mykey" as ptr, result as long
rec = winstring(result)
calldll #lib,"UPDATERECORD", rec as ptr, 10 as long, "joebloggs" as ptr, result as long
rec = winstring(result)
calldll #lib,"WRITERECORD", "MyDataDir" as ptr, "mykey" as ptr, rec as ptr, result as long
---
Actually I will write more friendly wrappers for the calls to the dll's eg
rec = UpdateRecord(rec,10,'Joe Bloggs')
call WriteRec(Dir$,Id$)
---
The data record I will have to impose some sort of limit on, say about 50k for as yet, I don't know how to make the size unlimited (which in PICK is, although the OS writes the record over overflow sections and making the record bigger than what it was supposed to be is not recommend). Perhaps I can make a MEMO link in the record itself which is just a pointer to another record. Also the C dll will not really be needed, but I am writing it so for purposes of speed. Once testing and I find the speed overhead marginal then I will just publish the functions as LB code. Anyhow I have progressed someway so this will not be vapourware *grin*
--- Update - Still August 2006
Never had I suffered so much from string function programming *Errrk". I have been betrayed by two functions I wrote which I thought were solid, but were bug ridden. A strength of a chain is a strong as... Anyway, once I have DYNREPLACE, DYNLOCATE sorted out, I need to have DYNIS and DYNDEL newly coded (and DYNDELREC_ and then I will present my dll with documentation to the LB community. My dll is coded in BCX basic (and that version of basic is buggy, believe me) and I can present that as well for anyone interested. So in another week I will have it ready,. I suppose I should get a web page for myself. Gird your loins readers, this is going to tickle your pleasure spots. (Gird I said, hell, ungirdle rather)
Update : 3 september 2006
The first release is
6/9/2006
I used this exercise for practice and it just goes to show. Multiply IT projects projection time x impossibe.to.get.later.than.that x 2. Probably exaggerating. Hmm, my minds gone pleasantly blank and vacuous. I forgot what I was going to say. A software simulation of a 'hard array' (compiled) is probably the same thing,except a software simulation gives more scope, albeit it slower. I was thinking of writing a object orientated driver in basic, with baby steps for starters. Create a class and methods, create objects from them, let objects inherit from other classes, do a save state on that objects footprint. Teach that object new tricks through a language/action interface. Anyway, bye bye for now.