gfa_copyfile problems

[dragonjim]

Hello,

I'm trying to work with inline files (or :files), particularly with regards to updating them with fresh information.

Looking through the exhaustive help file, I came across Gfa_Copyfile which should do the job. However, it doesn't seem to be working for me.

Here's the code I've come up with so far (simplified for easy reading):

CopyFile ":option" Over To cd$ & "option.dat"
Gfa_CopyFile "", ":option" [This should kill the inline :file]
Open cd$ & "option.dat" for Output As # 1
For n = 1 To 20
Print # 1; options(n)
Next n
Close # 1
Gfa_CopyFile cd$ & "option.dat", ":option"
[ or CopyFile cd$ & "option.dat" Over To ":option"]
Kill cd$ & "option.dat"

What is happening is this:
1. The new file "option.dat" is being created and the correct values are being written to it.
2. ":option" is NOT being deleted.
3. ":option" is NOT being updated.

Any ideas on what I may be doing wrong? Any help would be appreciated.

[649psoft2]

Interesting.

All I can come up with is "Bad Assignment Operator" for the commands that don't work as expected.

There is a very few rare typo's in the documentation or translation.

The inline file has great possibilities but only works a few ways internally.

So far mostly for monolithic compressed storage of
resources and data otherwise external to the .exe.

As you might know the inline files are also the form resources at the end of a .g32 file.

Since we now know they are packed and mimed they are
gibberish to the eye but if thay can be decoded we can
at then use regular form files and find the way objects
are defined in gb32 forms.

Then we can make human (or automated) form files,
repack and mime them and import them to the end of
.g32 files.

We could make form definition files from other languages usable to import to Gfa Basic 32.

Worth looking in to.

[dragonjim]

You make some good points in reference to the inline files. To add to your list of possible uses I would say they could be useful for:

1. Storage of password information (or anything to do with user security within the program, etc.) - to have to store it in a separate file risks breach of security or simply the chance of deletion.

2. Creation of basic update files for new builds which can be built interactively - i.e. grabbing the lastest version of a particular file or files and storing them into one file (rather than a mass of files) - to be expanded later.

3. I generally have an aversion to having a host of additional files with a program which I would consider more an accessory rather than major program (I hope that was clear!). The best example in the big wide world of Microsoft is their Helpfile program, with all html files and added graphics combined into one file. Once again, the inline file system would be ideal for this. (I used to use it for exactly this reason all those many years ago when I used to do hobby programming on my old Atari ST).

These are just some of the reasons why it would be useful to have this feature operational - or find out why I can't get it to work. I'm going to have a quick breeze through the German help file and see if there had been a typo...you never know.

[649psoft2]

Actullay I started to create a complete template for the various OCX object properties. I think this would be the
useful solution for dynamic forms in the inline file.

That's as far as I have gone so far.

You see a lot of coded dynamic OCX in examples but with only a small subset of properties.

With a full generic property sheet in the inline file I think
the New operator could be used to create instances of dynamic object variables in code or variables of properties from .dat or resource files could be imported at run time make morphable dynamic objects without changing the listing code so as to be available for a compiled .exe.

I manage to get a packed form from a .g32 file unpacked

It looks like compiled API type of C but I have to check on the un-mimeing.

[dragonjim]

I like your ideas on the use of inline for OCX, but, as I'm not totally au fait with ActiveX at the moment (but doing some furious surfing to try and catch up!), I can't really add or help you further.

Just one question...if you were able to create dynamic OCX objects, would this make the mandatory GFA .ocx file redundant?

As to my previous mention of looking for typos in documentation: if there are any, I can't find them.

[649psoft2]

I don't think it makes the .ocx file redundant this is rather is a concept to extend the flexibilty of gfa basic and these concepts could be of a lot of ideas including add on's and functional extensions of GFA basic to move forward such as Sjoke Hamstras idea
to extend the language to produce COM interfaces and object fuctionality.

Note that the 16 bit Gfa Basic produced .dll file and although the .lg32 library files
ad some fuctionality this way they are not a formal .dll outside of Gfa Basic 32.

The OCX provides a formal design environment to make the form objects and visualize them in the IDE. These are stored in the inline :{ packed part at the end of the .g32 files.

The following is a short Dynamic OCX coded in the listing:

'textbox on a form or window

'generic TextBox TextBoxName

Local TextBoxName_px1% = 120
Local TextBoxName_py1% = 50
Local TextBoxName_pwd% = 100
Local TextBoxName_pht% = 16

Ocx TextBox TextBoxName = " TextBoxName", TextBoxName_px1%,
TextBoxName_py1%, TextBoxName_pwd%, TextBoxName_pht%

TextBoxName.Text = "TextBox"
TextBoxName.BorderStyle = 1
TextBoxName.BackColor = RGB(255, 255, 255)
TextBoxName.ForeColor = RGB(0, 0, 0)
TextBoxName.ToolTipText = "TextBox"

Note that with the exception of the OCX command line the other lines
assign variable to the properties. They are only a subset of the properties.

The complete textbox property sheet is in the .ocx file to be distributed with the .exe.

The complete set of the textbox properties could be loaded into the :Files tab (or stored
as a Type structure as they are in windows C). They could then be sourced as a template
into the ,exe program where there are unknown numbers of textboxes and variations
of textboxes to be created. I guess properties could be loaded from external resource
files as it is but there is no full line guide template except as used during design time IDE form editor.

Anyway this is just a concept that could be tried. The files are sort of a container and it is possible to even load and .exe into them but I haven't been able to find the pointer to the inline files yet. They could be as dropped to a real file at runtime as per Gfa_Copyfile.

[dragonjim]

So, if I understand you correctly, a 'Dynamic' OCX is one coded within the program, whilst a non-Dynamic OCX is one created by GFA's Form Creator. Is that right?

[649psoft2]

Yes as decribed in the reply I guess a better discription would be "hard coded" in the listing.

I suppose what I am describing is to find a way to create OCX on the fly where the number and type of objects available have not been pre-defined without changing the code or .exe.

This is the essence of the idea behind COM objects but as you can see the implementation of COM is rather complex.

It is easy to "Set As Object" a compatable external Active X Control.

I have had trouble with the compatablity to some newer Active X Controls that don't initialize as expected with Set [control] as Object.