Kaju ZipShell.Completed Doesn't Fire

Add-Ons
#1

Kaju downloads my update OK and calls the shell command for unzipping, but ZipShell.Completed never fires and the system never goes past the “Processing” stage. Here’s the shell command:

/usr/bin/ditto -x -k /var/folders/ps/mpybq_x88xjcv900r6b323yr0000gp/T/com.company.appname\-temp1062648810/My\ App\ Name.app.zip /var/folders/ps/mpybq_x88xjcv900r6b323yr0000gp/T/com.company.appname\-temp1062648810/decompressed

Are the spaces in my app’s name an issue? If I paste the command into Terminal it seems to execute without errors.

Nothing happens with Kaju after the shell command is executed, but my app continues working. If I halt execution, the zipper’s properties are

image

Both FolderItems look correct and Exist.

#2

What OS and hardware? Is the M1 processor?

#3

Oh wait, the Mode = 0, but should be 1 (or 2, I don’t recall).

#4

Mojave and Intel MacBook. Just tested it remotely under 64-bit Windows 10 and seems to be doing the same thing, although downloading took a lot longer than here on the MacBook.

#5

Mode should be 1 (Asynchronous). I think something happened when the Kaju classes were imported into your project.

#6

I just dragged them from the demo app to my app in Xojo 2020r2.1. The demo app does work.

#7

To be clear, from the open project, not the files in the directory?

Try deleting the Kaju folder from your folder project, then copy and paste from the Sample app.

Either way, that Shell mode should be set to Asynchronous.

#8

Yes, the entire “Kaju Classes” folder was dragged from one Xojo IDE window to another, not from the Finder.

Deleted the Kaju Classes folder and then did copy-paste; same result.

#9

OK, change the shell mode manually via the Inspector and it should work.

#10

Yup, I can reproduce this, and it’s a Xojo bug. I’ll file the Feedback.

1 Like
#11

So I want to change the zipShell’s property before Decompress is called, yes? It has two “mode” properties: ExecuteMode and Mode. I’m changing Mode?

Neither is editable in the debugger, I’ll have to insert code.

#12

This in hsSocket.FileReceived works

Shell(shZipper).mode = 1 // ### added per Kem 2/8/21
shZipper.Decompress( file, targetFolder )
#13

Shell.Mode is API 1.0 which is why it doesn’t appear in the inspector. If ExecuteMode isn’t showing in the inspector, that will need a ticket as well.

#14

It appears in the inspector (see screenshot above) but is not editable.

#15

The screenshot above is not the inspector, it’s the debugger.

#16

You are correct, it’s the “Watch Pane” of the debugger (although Xojo doesn’t actually offer a true Watch List where one can specify which variables one wants to watch, which would be nice :slight_smile:)

None of the properties of a subclass of Shell are exposed in The Inspector.

#17

I mean, I can’t confirm that…

Screen Shot 2021-02-08 at 15.25.50
Screen Shot 2021-02-08 at 15.25.50562×526 52.4 KB

@Kem_Tekinay I guess it’ll be your responsibility to figure out what, if anything, needs tickets regarding this. Sorry I tried to help.

#18

I’m seeing the same thing you are, @Tim_Parnell. The Inspector lets me change the Execute Mode, and changing it to Asynchronous should be all that’s needed.

The ticket is that it doesn’t preserve that mode after copying from the other project. I’ll post that report here when done.

#19

image

Weird. But thank you for chiming in, your input is always welcome.

#20

That is very weird! You should file a ticket and attach the project as it is right now. There may be something hidden in the conversion between projects that caused the bad behavior.

Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.