Sorry your browser is not supported!

Ok, my general aim here is to write a program in Vb6 which exports files that can be read by a program written in DBPRO. Is this possible. :-s i hope so

Yes, entirely possible.

What you DO with the file once it's loaded into DBPro is another matter though.

Cheers,

Rich

Lol so what you mean is it wont be a walk in the park :-s .

Still it will be good to come up with several of the editors required for Eternal Destiny in VB6 because of its interface advantages.

The best approach is to ensure that you know how big the types are under VB, i.e. Integer is 4 bytes etc. You could load the file into DBPro using the Memblock commands and traverse the file according to what type sizes or data is stored in the file.

IN vb6 to my knowledge an integer is 2 bytes and a long integer is 4 bytes. And in dbpro integers are twice this size. correct me if i am wrong though

Hehe, that sounds mighty complicated for such a simple task.

VB and DB use a similar sequencial file system, so it'd be quite easy to make your own duplex format. In fact, you could copy your code from VB6 and paste it in your project, then all it'd need is some syntax changing. The basic principle is (psuedo code):

OPEN FILE "test.txt" FOR OUTPUT AS #1
WRITE STRING #1,test$
CLOSE FILE #1

Then...

OPEN FILE "test.txt" FOR INPUT AS #1
READ STRING #1,test$
CLOSE FILE #1

Just in case you (or anyone) are interested, here's a couple of tips that've proved invaluable to me:

I suggest using a bloated file format, have check strings, like a dummy string that is loaded and added to an accumulator string, but these strings are only there for debugging and organising your file format. For example, you might want a header "ED-LVL" and a footer "ED-LVL-END". Now, when you save these check strings, just save out the text, when you load them, load in as a dummy string, and add it to a string as well (which you reset before loading anything). Now when you get to the end of the loader, you can check the accumulated check strings against a preset one (I usually tell the code to copy the accum string into the clipboard). If the accum string matches the preset one, then it's all good, otherwise bail out before the innevetible crash a corrupt or mismatched file will cause.

Now you need to specify as much as possible when designing your format, maybe even having an extra set of string data that is for miscellanious use, like if you have 10 single on/off settings you want to store, make it 20, you will most likely need more later, this will save having to start from scratch with your files. It's damn near impossible to get it right first time, so buff up the data a bit to make it easy to adapt to new ideas.

Be sensible with the format, you can't just store it all as strings or bytes. If you have a 64x64 map using bytes, and 10 different strings to store, put the strings first, and use a check string to seperate the string area from the byte area, byte reading can easily over step the data's end if your not careful. Also, never store a floating point variable as a string, only use WRITE/READ FLOAT - using strings will chop the decimal point off.


Van-B

Just to correct myself about the type sizes in VB, here are the actual sizes. Straight from the horses mouth so to speak

Is that up to date? I thought that VB strings were unicode, and unlimited in length - I could be wrong though. I'm well out of date with VB.

Anyway, the sizes, ranges and VB equivalents are listed in the source box.

And to complete the list, these VB types have no exact DBPro equivalent:
bool, integer, currency, date, object, variant

It may be possible to get string conversion using a VB byte array.

I'm sure that you are right about the Unicode Strings, I obtained it from may be an older version of my MSDN disks, but the strings can be converted to standard format. It's more important to note the actual Integer and float sizes though.

Van B...
You almost wrote a spec for XML there! Just put < > and </ > around your check strings and you're there.

Personally, I always store everything as strings, and convert it in code. It makes the file more predictable.