Cross-platform stack files

[jmk_phd]

My cross-platform (Mac/Win) app saves a datafile generated by the app as a LC stack file, which can be opened/read later to generate a report of the results. It's worked fine on each platform for over a year.

However, a client just sent me a datafile stack generated on a Win computer that can't be read by my Mac app. I'd always assumed that LC stack files were readable across platforms.

When I open the Win-generated datafile stack in a text editor at my end, most of its contents appear intact, although the line-breaks apparently differ from those typical of a Mac-native datafile.

Is some conversion necessary when importing a Win-generated LC datafile stack into my Mac LC app?

Thanks. jeff k

[FourthWorld]

1. How was the file sent?
2. What are the first 8 bytes of the file?

[dunbarx]

Richard.

The OP had this working for a year. What might any dissection of the actual file contents indicate?

Craig

[FourthWorld]

The OP had this working for a year.

It stopped working. Something changed.

What might any dissection of the actual file contents indicate?

What changed.

Specifically, if the identifier of the file is intact. That will rule out a lot of possibilities.

[jmk_phd]

Richard --

Thanks for your reply.

In fairness to Craig, I should've been more explicit that while the app works fine on *each* platform, I've never before tried to open a datafile stack created in the Win version on a Mac (or vice versa). (Inasmuch as these datafiles contain confidential information, they'd rarely if ever be shared in real life.)

The client sent me the datafile stack via email. Before posting my initial question here, I did confirm that I could email a similar datafile (Mac to Mac) to myself without problem. So it seems unlikely that the file was corrupted in transit.

I can open the Win-generated datafile stack from within LC, but it opens on my Mac as a single entirely blank card. (In other words, all but the first card are missing, and even the fields included on that first card are missing.)

So apparently LC does recognize this as a stack file, but not its contents.

When the Win-generated datafile stack and datafiles generated on my Mac are compared in a text editor, the most obvious difference is that even in the first few lines these differ with respect to linefeed and return chars. I don't know whether this is the issue, nor the solution.

jeff k

[FourthWorld]

Can you post the errant file here? If not, can you reproduce the issue with any other stack that you can post?

[bogs]

The client sent me the datafile stack via email. Before posting my initial question here, I did confirm that I could email a similar datafile (Mac to Mac) to myself without problem. So it seems unlikely that the file was corrupted in transit.

I wouldn't agree with that statement, unless you have separately duplicated the entire case mailing setup and each step the client took mailing the attachment.

Real life work experience -
Client mailed attachment from gmail to an MS Exchange run server to home email account - attachment readable at all ends.

Client emailed attachment from gmail directly to home account, and from home account to gmail - again, readable at both ends.

Client emailed attachment from home account to MS exchange, then to gmail from MS Exchange - attachment readable at MS Exchange account, but not at gmail account.

I'm sure you see the problem was at the MS Exchange server, and only going from there to gmail apparently, but MS support called us with the client on the line saying it was somehow our email services issue corrupting the attachment

(The client and I had a pretty good laugh about it later)

[FourthWorld]

For the 8 bytes, but this in a button and run it, and report back what winds up in the Message Box:

Code: Select all

on mouseUp
   answer file "Select your LiveCode stack:"
   if it is empty then exit to top
   put it into tFile
   open file tFile for binary read
   read from file tFile for 8 bytes
   close file tFile
   put it
end mouseUp

[jacque]

It might also be useful to know how the data is generated and saved. Does the user type into fields or paste? Or is the data retrieved from a file on disk?

How are the entries saved? In fields? Or custom properties?

[jmk_phd]

My thanks to all. I'm very much aware that you're volunteering your time here.

In reply to forum member "bogs" : You are entirely right that I ought not rule out the possibility that the stack file simply was corrupted in transit. The client employs a university mail server that can be a bit flakey. I've asked that he re-send it (preferably this time in a .zip archive), but he is a "busy person" who does not often reply to my requests in a timely manner.

Richard: Thanks for the snippet to read the first eight bytes of the problem file, which I should've provided just by reading the text of the stack file. The result is

REVO7000

As far as I can tell, this doesn't differ from readable stack files.

Jacque wrote:

It might also be useful to know how the data is generated and saved. Does the user type into fields or paste? Or is the data retrieved from a file on disk?

How are the entries saved? In fields? Or custom properties?

That's a difficult question to answer. It's a rather complex application designed to record and score responses to the Rorschach Inkblot Test. The stack that is created and saved as a datafile includes multiple sources of information: demographic information from a modal dialog window, textual information typed into a field by the user (with additional characters inserted via key commands), and the combined result of input from over four dozen scoring buttons. All the data are assembled and inserted into preconfigured fields of the datafile stack that's saved to disk.

My application -- dubbed Hermann10 -- is freely available for download online from its original author's website, in case you're curious either to see my programming or just to see the Rorschach inkblots:

http://www.choca-assessments.com/rorschach/

Both Mac and Win versions are available. Scroll down to the bottom of the page and you will find a video tutorial that I created in order to walk a new user through using my LiveCode program. I do believe that it exemplifies what is possible using LiveCode.

Again, thanks to all.

jeff k





Frankly, I don't believe

[bogs]

In reply to forum member "bogs" : You are entirely right that I ought not rule out the possibility that the stack file simply was corrupted in transit.

It is a distinct possibility, to test something like that, I would suggest the errant client copy the file to a usb, verify it can still be read on the Win system from the usb, then carry it manually to the Mac computer to try it, i.e. eliminate the mail possibility from the equation.

I think the answer may be simpler than that, though. Your answer to Jacque's question was in part ...

It's a rather complex application designed to record and score responses to the Rorschach Inkblot Test.

Are there likely to be linefeeds/carriage returns in the responses? How long are these responses? And lastly, how did you code those responses to be recorded, with return or cr or lf? The reason I ask is this part of the dictionary entry on CR/LF -

Revoluton translates the linefeed constant and its synonyms into the appropriate end-of-line character for the current operating system. However, you should keep this nuance in mind when processing data from another system, which LiveCode has not translated: return is not ASCII 13.

The stack files themselves are readable across platforms, so your question generates a lot of interest.

[jacque]

Bogs' comment about line endings is what I was thinking of too. But translation only happens when getting files or data from outside sources, and it sounds like this app is generating data internally where LC would be managing the text itself. No conversion should be needed in that case.

The fact that the fields are empty is interesting, and could imply that the content contains characters that LC uses to mark the end of the field text. I'm not sure what that character is but it may be appearing at the beginning of the text.

Or am I wrong that the fields are empty? Do they appear at all? If not, then the stack file itself may be altered in such a way that it opens but the layout can't be read.

Just some guesses.

[FourthWorld]

Richard: Thanks for the snippet to read the first eight bytes of the problem file, which I should've provided just by reading the text of the stack file. The result is

REVO7000

If would have to be a binary read to avoid text encoding murkiness.

Thanks for that value.

What is the LC version number you're using?

[jmk_phd]

My thanks to everyone for helping to troubleshoot the corrupted datafile stack.

The problem turns out to have been far more mundane and tangential to LiveCode itself: The client had tampered with the structure of the stack file. I’ve finally received this email reply to my inquiries:

I must have messed it up by trying to take the name out....I searched for the patient's name and replaced it with something else.

This was entirely unanticipated. I’d forewarned him that while the patient’s identifying information would be visible at my end, this shouldn’t be an issue: As a licensed clinical psychologist myself, I’m bound by the same confidentiality rules. (Still, I’d even volunteered to write a mini LC app to delete identifying information from the stack file in case this was a concern for him.) But he just plunged ahead on his own with altering the stack file in a text editor unbeknownst to me.

I must contain my anger and frustration because I’m still working on another LC project for him, but I do wish to apologize for having squandered everyone’s generous time and effort. I’m deeply embarrassed at not having done due diligence and will be far more careful in the future.

jeff k

[jacque]

No problems, please don't feel bad. It was an interesting puzzle and it piqued my curiosity.

Also, it isn't possible for anyone here to take up someone else's time. We show up because we like to, and if we're busy we don't answer. You couldn't waste our time any more than we've chosen to waste it ouselves. As for customers who just don't get it...I went through one of those things not two days ago. Believe me, I think we can all empathize.