OpenXTalk Forums

However I just spotted a folder called: org.openxtalk.coremidi.paulmcclernan and another one called org.openxtalk.hoerwi.customcheckbox so 'somebody' knows what to do . . .

The clue may be in the 'paulmcclernan'.

Opening the 'api.lcdoc' document inwith that folder with BBEdit reveals something that SEEMS relatively straightforward.

The 'api.js' file LOOKS as if someone (err, possibly Paul) has taken the lcdoc text document and run ti through something that turns it into JS (erm, javascript???).

ALL of the folders contain an 'api.js' file, and some also contain a 'guide.js' file.

Something 'dynamic' has obviously gone on as they display details about my system's file structure:

"{
"name": "com.livecode.widget.headerbar",
"display name": "Header Bar",
"group": "Extensions",
"location": "/Users/richmond/LiveCode/OpenXTalk 1.963.1rc3.app/Contents/Tools/Extensions/com.livecode.widget.headerbar/docs/guide","

No it won't, because at that point it's not generated.
Have a look at the file
/openxtalk contents folder/Toolset/libraries/revdocsparser.livecodescript
(in bbedit) to see what I'm talking about regarding the generation routines being complex.

Also see line 10829 and downwards in the stack "revIDElibrary". Yes, you read that right: line 10829 to 11427.
1402 lines of complexity that could be *cut* in my opinion, in favour of my approach above.

PARSING UTILITIES

Maybe I should have that carved on my gravestone.

Pardon my naivety, but would things be simpler if the entire documentation were 'just' written as a continuous text file (OK, rtf or html if you want to be tarty), with headings such as "MOVE" and a line of dashes to symbolise the end of that section?

richmond62 wrote: ↑Tue Jul 16, 2024 5:32 pm

PARSING UTILITIES

Maybe I should have that carved on my gravestone.

Pardon my naivety, but would things be simpler if the entire documentation were 'just' written as a continuous text file (OK, rtf or html if you want to be tarty), with headings such as "MOVE" and a line of dashes to symbolise the end of that section?

As my comments above. Multiple text files, as would be from different plugin authors, but loaded into a plain stack.
You know, our native format we should be championing
Just my opinion. Probably not shared by anyone.

Wayback, wayback . . .

https://web.archive.org/web/20161222230 ... docu_2.rev

This SHOULD read the documentation and then offer you the chance to export it as a PDF.

Currently:
- -

Here it is either crunching away with LC 8.0.0 or stuck: shall just have to wait and see:
- -
What is obvious from that screenshot is that the stack CAN get hold of the documentation: presumably the 'trick' is to open the thing with scripts turned off and disable anything to do with SQL and a Database.

To bad that Björnkes BvG Docu 2 doesn't work on LC 8.
No dict.index array any more.

I don't entirely believe that:
-

richmond62 wrote: ↑Tue Jul 16, 2024 5:20 pm The clue may be in the 'paulmcclernan'.

I'm sure it is, and he did try to post a huge 'how to' - but I think I lack the necessary internal CPU to effectively process his instructions

In other words, I'm too dense to get my noggin around how it works.

I think exporting it to a huge PDF would be relatively easy.
The issue comes when you want to change any of that content of course (I mean, yes - there is software to edit PDFs, but always best to edit the original then regenerate a PDF in my opinion).

I don't know - I may just 'go my own way' with the dictionary - just as a test, not to inflict on anyone.
Sh*ts and giggles, as they say.
Which is all very well until someone giggles and sh*ts.

Suck the text out of the PDF into a text document.

The text document can then be mucked around with as much as you like.

Here's a bonkers thought:

https://apkcombo.com/livecode-dictionar ... hk.LcDict/

Just downloading Android Studio to poke around inside that.

Ah: that's "2.5.3" which on my Android phone says it for LC 10: so I'll need to download an older version.

https://apkpure.net/livecode-dictionary ... load/1.5.0

I wonder if this might be the reason why the dict.index array disappeared with LC 8.0?
- -
https://livecode.com/book-bundle/

That is still available: no-one pointing out that it is out-of-date of course.

I just shoved the suffix '.zip' on the end of the .apk file and unzipped the thing.

This is the Android thing for LC 8, and the bundle contains an sqlite datebase that is 7.3 MB.

The problem now is to find a version of the Android app between number 1.5.0 and 2.5.3 to get the sqlite thing for LC 963.

Let's see what version 2.0 contains:
- -
OK: the folder:
- -
contains something rather attractive.

Opening that file with BBEdit:
- -
Makes me think 'Markdown or HTML'.

Seems to be markdown.

OK: I stand corrected:
- - -
Not particularly useful.

Going to bed: will "see" in the morning.

Bernd Niggemann

has just made available a new version of his Tiny Dictionary:

https://livecodeshare.runrev.com/stack/ ... Dictionary

Several versions of several stacks to download and play with here:

https://forums.livecode.com/viewtopic.php?f=67&t=28731

2011: https://www.mediafire.com/?eteillibdzzcbxc

Hmmm, okay - more testing is required when I have more time I think, as at the moment this appears fairly broken - but it may just be that obviously it needs tweaking from the LCC files it's expecting to the OXT names.

Just got back from a vaca. Still trying to catch up on various forums. I don't really bother trying to use forums when I only have my phone to access them from. I'll have to go back and read this thread in its entirety .

I just wanted to point out that you can, instead of using a group, set the label of a graphic object to quite a few character (not sure exactly what the char limit is) and then set show label. The text does do a basic word-wrapping thing based on the graphic's shape too, so you can get just little bit that fancy typography stuff going on in a way a that's similar to page layout program.

There is indeed a 'tool' mode, that is: set the tool to "text tool" that seems to have been long forgotten and has no Tools palette interface. Using it produces a graphic object.

I believe object names have a wired limit of 255 chars.

IIRC the text tool was used for painting text into a bitmap, similar to how text was handled in MacPaint. Maybe useful for some obscure art, but I'd guess they stopped providing a UI for it because that text is cumbersome and ugly compared to just putting a field over a bitmap.

@ tperry. I've been reviewing Quick Dictionary and offer a small improvement. This allows entries to be updated while both adding and deleting characters, and displays all entries with returnKey in an empty search field (to browse a-z). Seems to work in Windows. I suppose you could also save the stack while displaying all entries making it the default rather than empty, but this increases the size of the stack about 135 k.

In the script of fld "Cerca" (the search field), at the bottom:
on returnInField
if me = empty then textChanged --display all entries
end returnInField