Phantom pathname

[dunbarx]

I use a hardware interface for certain projects. It comes with a framework that allows it to communicate with LC. I can send and receive data from the interface by using commands and functions built into the software. It isn't pertinent, but the interface can read, say, a thermocouple or close an external switch.

When the framework package was originally opened, it parked a bundle in the Applications folder. From there any stack I made could access that bundle, and communicate with the interface. If I wanted to place a copy of that stack onto another machine, I also copied the bundle and placed it in the same folder there. Works fine.

After about four years I suddenly find myself (on the same machine with the old "connectable" stack) unable to make a new stack that can find that bundle. But I can make a copy of my "connectable" stack, clear it completely of all controls and code, and change in any way. It still works fine. So I can make new projects using the old stack as a "template", saved under a new name in a new stack file. I just cannot do so with a new stack.

If I change the name of the folder in which the bundle lives, the "connectable" stack cannot find it any longer. Change the folder name back, and all is well. Therefore the pathname to the bundle must be explicitly stored somewhere in the "connectable" stack.

Where is the "connectable" stack storing the pathname to that bundle? How do it know? I cannot find any reference at all.

Craig

[FourthWorld]

It may be instructive to dump the stack file into a field and search the field for the bundle name.

[SparkOut]

I can give no help here, but I am curious to know what hardware device you are using for this interface.

[dunbarx]

@Sparkout.

I have mentioned it in passing several times over many years. It is called "Service USB Plus". Among other items, it is made in Germany by:
https://bkohg.com/interfaces_e.html

It is not cheap. But it has 16 digital I/O ports and two analog, as well as a PWM output. I used four of them in a for-pay project in 2014. It is a general purpose gadget that can read electrical values and output digital data. So currently I am building in-house controllers, reading thermocouple millivolt values, reading the forward voltage of LED's, reading the output of an encoder used as a tachometer and turning on relays.

@ Richard. Will do. Thank you. How does one dump the stack file into a field?

Craig

[bogs]

Possibly this is what I was doing when I was figuring out why Mc wouldn't run -

Stack in field...

[SparkOut]

@Craig thanks. I discovered the Velleman VM110N board https://www.amazon.com/Velleman-VM110N- ... B007OWQ23Q and have been impressed with the bang per buck, although not as sophisticated. It is the same as the K8055N that is the self-assembly kit version, but the VM110N comes completely assembled and soldered. It is supported for Windows with a supplied dll (which I got a lot of help to make work with LCB last year) and there are also projects that have been written to use it for Mac and Linux. I have interfaced Raspberry Pi Zero W to things with it. I was interested in what you were using just to keep aware of what "things" are out there that can work with LiveCode, as it's all relatively new to me.

[dunbarx]

You guys are great. Thanks.

So I loaded the stack into a field as a binFile, and right after the contents of the stack script, which was at the top, was this:

““˘˘ÃÃÄÌVE‘vfTEster ˇˇˇˇ//Applications/Bk Folder/susbrevolution08.bundleU(Text),unicodeUCourier,unicode
U(Message),unicodeU (Message)U(Message),unicode

The above is one line. "BK folder" is the folder containing the bundle. "vfTester" is the name of the stack and the stack file.

So it is indeed part of the stack. AHA. You guys are great. Thanks.

But, er, where is it, exactly? I need to be able to put this into other stacks, and am afraid of simply loading that line by reversing the process, putting the field, er, into the stack file.

Craig

[FourthWorld]

It's been a long time since I tried reverse engineering the file format. But if you've already checked the scripts, maybe that's in a custom property? Or so entry in the externals?

[dunbarx]

Richard.

There are no custom properties in the stack. So I added one, reloaded the binFile into the field, and the custom property appeared in the same line as the bundle pathName reference.

Here is the issue. The controls in the original "connected" stack were all deleted, along with all scripts and custom props. The stack was renamed and saved into a new renamed stack file.

But the length of the stackFile dump is almost 2 Mbytes. It includes ALL the scripts and properties of the deleted controls cards and stack. The fact that these linger in the new stack is baffling, but at least tells me that the connection to the bundle is also preserved (somewhere) and that is why it works. How do it know?

In a new small stack named "binFileTest", with a couple of buttons with small scripts and one field, I dumped the stack file into the field. The length of that dump is about 2.4K

But what you call "reverse engineering" is perhaps the way to do this to the new stack, and an interesting exercise in its own right. I could add the line from the original stack containing the bundle reference, and see if it "takes". So, how would I upload the modified dump to the stack file? Something like:

Code: Select all

put fld 1 into URL "binfileTest:/Users/craignewman/Desktop/binFile.livecode" 

I am sure this is wrong.

Craig

[dunbarx]

Sparkout.

The Velleman gadget seems to be Windows only. The Service USB Plus has a LC framework. Though the cost is high, I am sold for that reason alone. I have used eight of them here and there.

Craig

[FourthWorld]

Have you queried the stack's externals property?

[jacque]

There are often custom property sets used only by the IDE. See if there's one for the working stack.

[SparkOut]

@Craig, there's a Velleman dll for Windows, but as mentioned, there are projects people have created so it can be used on Mac and Linux. I have coupled it with Raspberry Pi and Pi Zero W myself.

[dunbarx]

Richard.

Thank you. The externals property was it. I can now make any new stack work, and place the bundle anywhere.

This means, though, that the stackFile contains much data, built and recorded continually from the totality of the controls, properties and handlers within that file as those elements are created and modified. This data persists even when everything possible to delete in the actual stack itself is in fact deleted. The stackFile is a time capsule of all that history. Is this a feature?

Jacque, I had deleted everything, including custom property sets.

Ahhh.

Craig

[FourthWorld]

Richard.

Thank you. The externals property was it. I can now make any new stack work, and place the bundle anywhere.

Glad that worked out.

This means, though, that the stackFile contains much data, built and recorded continually from the totality of the controls, properties and handlers within that file as those elements are created and modified. This data persists even when everything possible to delete in the actual stack itself is in fact deleted. The stackFile is a time capsule of all that history. Is this a feature?

Have you checked for unplaced groups and non-visible objects?

And run the compact command on it?