The Secret is ...

[StanHelton]

Same as it has always been.
Define the problem.
Evaluate the available data.
Plan the execution.
Execute.
Big projects require big plans.

Progress is being made. Earlier today I discovered the WRAP$ and UNWRAP$ commands in PBWin 10.03. That alleviates the need for regexpr.

Step by step and don't skip any -- that's the secret.

[Michael Mattias]

As a standalone post, that must be corrected, as WRAP$ and UNWRAP$ do not support all the functionality of REGEXPR.

Methinks perhaps a little context is necessary. That, or maybe you should have "replied" to something instead of starting a new thread.

[StanHelton]

As a standalone post, that must be corrected, as WRAP$ and UNWRAP$ do not support all the functionality of REGEXPR.

Methinks perhaps a little context is necessary. That, or maybe you should have "replied" to something instead of starting a new thread.

Context:
We don't need all the functionality of REGEXPR, only the brackets and a few other symbols. Using a simpler tailored system. Folks offered suggestions in the REGEXPR thread, but the learning curve is too steep. This way future contributors will have an easier road to hoe.

Source code is a WIP and zips to 39 Kb. It contains 8 source code files and 1 resource file.

Working Directory zips to 32 Mb. It contains all the DLL/OCX files from VB6Ent, code contributed by members of this forum, several #INCLUDE files not yet added into the Project, and the reference files I've found most useful.

Happy to share either or both with anyone who is interested. If anyone has an idea for the translator, or wants to put hands-on, I would also appreciate any help at all. It's a big project for one person. (I'm down to translating the CodeLine.)

[Michael Mattias]

Oh.. I should have checked in which forum this was posted, shouldn't I?

This is all specific to the "VB [source code] Conversion Project."

[StanHelton]

Shiftint the focus of the thread ...

Oh.. I should have checked in which forum this was posted, shouldn't I?

This is all specific to the "VB [source code] Conversion Project."

Don't be snippy. You asked for "context". I gave it to you. As for the project, these days I tend to view everything through that lens. 90% of what I do lately every day is this project. We all, every member of this community, already know how big this thing is and we all already know your opinion of it.

Question for you: Do you have any code to extract information and resources from a FRX file? That would actually be helpful.

[Wayne Diamond]

Stan,
FRX is a proprietary format as you know and unforch there's no reverse-engineered info about it at wotsit.org, but I did come across this app which extracts graphics from FRX files...

http://btmtz.mvps.org/gfxfromfrx/

Note however that it doesn't do this by reading the FRX files native structure... instead it simply scans the FRX file for known image format headers ("BM", "GIF89" etc).

If that's the approach you end up taking then let me know, as I've written a lot of code to detect the headers of a lot of different file formats, and then read their header to determine the actual size... I was planning on using it in a commercial app though *scratches head* ... ... plenty of options there though, SLL perhaps for example

See also http://www.vbforums.com/showthread.p...rx-file-format regarding this in regards to how the FRM references the FRX ... ie:


Also another program though i dont think its open source but might be helpful during your dev, FRXSplit - http://frx-split.software.informer.com

I havent looked at an FRX file in a hex editor in over a decade but if it turns out fairly simple to reverse engineer I might be able to have a crack at it (that is, figuring out how to properly read its structure, as opposed to simply scanning for image file headers but at least that remains a backup option)... i'm just a bit short on time at the moment due to another project

[Michael Mattias]

I was not being snippy; au contraire, mon amis I was pointing out my own inability to pick up or lest infer context from the forum in which you posted.

Do you have any code to extract information and resources from a FRX file? That would actually be helpful.

Since I don't believe in mindless verb-for-verb, statement-for-statement porting at the source code level, no, I don't.

Now, THAT was snippy!

[StanHelton]

I was not being snippy; au contraire, mon amis I was pointing out my own inability to pick up or lest infer context from the forum in which you posted.


Since I don't believe in mindless verb-for-verb, statement-for-statement porting at the source code level, no, I don't.

Now, THAT was snippy!

Can always count on you, Michael. If this were a "mindless ... porting" it would have been done already. 'Nuff said about that.

[Wayne Diamond]

Michael, the only thing mindless is how much time you waste trolling in threads that you have nothing to contribute to; just simply nothing better to do out of boredom. Granted it is mostly your own time you're wasting, but you're also slowing down our Poffs searches. Give Stan a break, I don't see him pissing on any of your ideas. At least he's getting something done, huh?

[StanHelton]

Stan,
FRX is a proprietary format as you know and unforch there's no reverse-engineered info about it at wotsit.org, but I did come across this app which extracts graphics from FRX files...

Wayne, thanks for that link. Downloaded and evaluating.

Note however that it doesn't do this by reading the FRX files native structure... instead it simply scans the FRX file for known image format headers ("BM", "GIF89" etc).

Sometimes a hammer is really all it takes.

If that's the approach you end up taking then let me know, as I've written a lot of code to detect the headers of a lot of different file formats, and then read their header to determine the actual size... I was planning on using it in a commercial app though *scratches head* ... ... plenty of options there though, SLL perhaps for example

Wouldn't want to compromise anything that makes money for you. I haven't decided how to approach FRX and the files in it. For now I can get everything necessary to make a functional WINDOW/DIALOG in PB from the FRM file.

Yes, the FRX is a big mystery, but as I pick up tidbits here and there my growing impression is that it is only a flat file with an obfuscated set of embedded controlling headers, kind of like the way MS-DOS used to handle disk storage. Just a suspicion at this point, though.

See also ...

That discussion was interesting, got another d/l to evaluate for the project out of it.

Also another program though i dont think its open source but might be helpful during your dev, FRXSplit - http://frx-split.software.informer.com

Hmmm. Shot myself in the foot on this one. Recently converted to NIX for my internet access and it won't download to that OS. Good news is, if I can work with the your first suggestion this would be overkill.

I havent looked at an FRX file in a hex editor in over a decade but if it turns out fairly simple to reverse engineer I might be able to have a crack at it (that is, figuring out how to properly read its structure, as opposed to simply scanning for image file headers but at least that remains a backup option)... i'm just a bit short on time at the moment due to another project

Not a problem. FRX files are actually on my back-burner right now. Currently digging into VB6 objects - watching what it does and building things that do the same job. (WARNING: Disparaging remark follows: They never should have called it "Visual" - it's 80% OOP even for the simplest tasks! "Oops Basic" would have been a better name.)

Thanks again.

[Wayne Diamond]

Ok! good news ...

As curiosity always gets the better of me I couldn't help but do a quick test then ... anyway basically it seems that an FRX file is simply a 12-byte header (the last dword being the Size, i havent checked the other two but one is probably Offset, the other possibly Type), followed by that media file ... then if there's another media file, there's another 12-byte header, followed by the data for that media file, and so on ... really very simple.

So basically the structure is like this (it has no actual formal header itself though ie as if to say "Im an FRX file", it just gets straight into it):

[Item #1 Header] - 12 bytes
[File #1 Data] - xxx bytes
[Item #2 Header] - 12 bytes
[File #2 Data] - xxx bytes
[Item #3 Header] - 12 bytes
[File #3 Data] - xxx bytes
...etc...

Leave it up to me, I'll have an FRX extractor in the Source Code forum within an hour or so. (Saves me having to give away any of my proprietary code too)
Gotta love reverse engineering at 4am on a Tuesday morn

[edit] Ok, done ... Im still not sure what those other two dwords are but theyre of no apparent importance to this task at hand.

http://www.powerbasic.com/support/pbforums/showthread.php?p=469197

Unlike the previously mentioned tools like gfxfromfrx, this demo actually properly walks the FRX file using its own (very simple) format.

[StanHelton]

Ok! good news ...

... anyway basically it seems that an FRX file is simply a 12-byte header (the last dword being the Size, i havent checked the other two but one is probably Offset, the other possibly Type), followed by that media file ...

So basically the structure is like this (it has no actual formal header itself though ie as if to say "Im an FRX file", it just gets straight into it):

[Item #1 Header] - 12 bytes
[File #1 Data] - xxx bytes
[Item #2 Header] - 12 bytes
[File #2 Data] - xxx bytes
[Item #3 Header] - 12 bytes
[File #3 Data] - xxx bytes
...etc...

Awesome!

... Gotta love reverse engineering at 4am on a Tuesday morn

Gotta say it. Your 4am results seem to work better than my 3:30am results.

[edit] Ok, done ... Unlike the previously mentioned tools like gfxfromfrx, this demo actually properly walks the FRX file using its own (very simple) format.

Very Good AND very quick.

Just checked that off my To-Do list. Thank you, Wayne!

[Wayne Diamond]

You're welcome, it was a fun little escape from the grind of my current project too. Glad I was able to contribute at least in some little way to what I know is a massive project! (u might as well outsource little bits like this where possible to free you up for the more core stuff)

[EDIT!] I just made a slight edit to the code ... the Offsets as seen in the .FRM files are normally shown as a 4-byte hex, such as "0332", but if it's greater than FFFF then it no longer uses a 4-digit hex, but simply the full hex number, be it 5, 6, 7 or 8 digits. The code fully accounts for that now.