Tag: Livecode

Posted on

Mac *.txt.rtfd to *.txt

In a recent project, an assistant used TextEdit to supposedly save documents as pure (UTF-8) text files. We managed to fix the workflow, but I was left with a bunch of Zip files full of *.rtf from TextEdit. On a Windows or GNU/Linux machine, these files show up as what they are: folders that contain a rich text document (and potentially other stuff). I needed text documents.

After a bit of searching and tweaking, I got the following shell script to convert all the rich text documents in these folders/containers into text documents:

find . -name '*.rtf' -exec unoconv -f txt {} \;

There was a problem, though. The files all had a name containing important meta data. So I had the folder with the name of the file, and inside this folder the file but it was called TXT.txt (converted from TXT.rtf). I’m sure there’s a quick way in a shell script (if you know one, please share it in the comments), but I got stuck with the shell.

Enter LiveCode. Here’s a script that does just that. I guess I could have called the above shell script, but I already had this.

on mouseup
-- INPUT: select a folder with the *.txt.rtfd folders
answer folder "Input: Choose folder:"
put it into infoldername
set the defaultFolder to infoldername
put the folders into listoffolders
-- filter . and .. can cause problems
filter listoffolders without "."
filter listoffolders without ".."
-- OUTPUT: select a destination folder
answer folder "Output: Choose folder:"
put it into outfoldername
repeat with i = 1 to the number of lines of listoffolders
put line i of listoffolders into currentfolder
revCopyFile infoldername & slash & currentfolder &
slash & "TXT.txt", outfoldername & slash & textname
end repeat
end mouseup

Full LiveCode stack here on OSF (it’s nothing more than a button and a text field with a basic log).

Posted on

Livecode: write document on Android

Android does not allow apps to write just anywhere as a matter of safety. That’s probably generally a useful feature, but this time I wanted to save data to a text file that is accessible to the user (me). The official guide wasn’t really helpful in this case, because there are ways to save data on Android that are not accessible by the users — e.g. for settings.

Apparently the ‘easiest’ way is to save like this:

set the defaultFolder to specialFolderPath("external documents")
put field "write" into URL ("file:test.txt")

The other (common) special folders (“documents”, “desktop”, “engine”) don’t seem to work on Android.

OK, but where is this file we created? Here:
Local/internal storage/Android/data/com.yourcompany.yourapp/files/test.txt

Not the most intuitive place to me, but whatever, I can access this file from the Android device.

Posted on

Livecode: resolving “could not compile service support class”

I’m not going to tell you how long I’ve spent figuring out why LiveCode wouldn’t compile to Android, throwing “could not compile service support class” errors. Apparently this is one of the more common errors when compiling to Android, but typically this indicates a problem with the “mobile setup” (Android Studio, Java).

This was different. I had LiveCode (9.0.3) setup on a Windows machine, Android Studio installed and properly setup. The “mobile” preferences looked OK (path to Android SDK and Java were present and correct), and most crucially, using this setup I had compiled stacks successfully. Now I had a very simple stack and suddenly I got this error. Shockingly, the stack that had compiled an hour earlier wouldn’t compile any more. I tried many things, and sometimes the stack that was ‘good’ before would still compile, but sometimes it wouldn’t.

It turns out that although LiveCode generally is not case sensitive, it actually can be. I had this one line in my code (this code actually doesn’t work on Android, but I wanted to test whether it works):

set the defaultFolder to specialFolderPath("Documents")

it should have been:

set the defaultFolder to specialFolderPath("documents")

Yes, really, that was all. So in this instance, LiveCode was case sensitive, and quite atypically it didn’t detect the error during coding (LiveCode’s errors when compiling for mobile can be quite cryptic/useless).

Now, I also found that once I got this error, LiveCode would fail to compile anything (yes, even an empty stack) — until I restart the program. So I learned two things here: first, LiveCode can be case sensitive, second, when LiveCode throws this error, I need to re-start the program before trying to compile again.

Posted on

LiveCode: The package appears to be corrupt on Android

I’ve spent a while figuring out why my LiveCode app on Android wouldn’t install. It was quite odd given that I have compiled and installed other apps from the same machine on the same tablet, but I couldn’t even get an empty card to work. Several pages on the web pointed out that “The package appears to be corrupt” cannot be the case for LiveCode, and I did allow external apps to be installed (otherwise I wouldn’t even get this far).

It turns out that I forgot to set the right key! Of course, once I figured this out, it seemed to obvious, but I needed the setting under “Standalone Application Settings…” to look like this:

I’m putting this out there because none of the pages discussing the “The package appears to be corrupt” error on Android and LiveCode seem to mention this.