Phantom pathname
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Phantom pathname
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
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
-
- VIP Livecode Opensource Backer
- Posts: 9840
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Phantom pathname
It may be instructive to dump the stack file into a field and search the field for the bundle name.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Phantom pathname
I can give no help here, but I am curious to know what hardware device you are using for this interface.
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Phantom pathname
@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
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
Re: Phantom pathname
Possibly this is what I was doing when I was figuring out why Mc wouldn't run -
Re: Phantom pathname
@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.
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Phantom pathname
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:
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
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:
The above is one line. "BK folder" is the folder containing the bundle. "vfTester" is the name of the stack and the stack file.““˘˘ÃÃÄÌVE‘vfTEster ˇˇˇˇ//Applications/Bk Folder/susbrevolution08.bundleU(Text),unicodeUCourier,unicode
U(Message),unicodeU (Message)U(Message),unicode
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
-
- VIP Livecode Opensource Backer
- Posts: 9840
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Phantom pathname
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?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Phantom pathname
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:
I am sure this is wrong.
Craig
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"
Craig
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Phantom pathname
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
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
-
- VIP Livecode Opensource Backer
- Posts: 9840
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Phantom pathname
Have you queried the stack's externals property?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Phantom pathname
There are often custom property sets used only by the IDE. See if there's one for the working stack.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Phantom pathname
@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.
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Phantom pathname
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
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
-
- VIP Livecode Opensource Backer
- Posts: 9840
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Phantom pathname
Glad that worked out.
Have you checked for unplaced groups and non-visible objects?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?
And run the compact command on it?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn