Image Picker 'Image access' limitations

Can you / anyone please explain to an old woman what this is really about.

1 Like

In the most simple case, when clicking or dragging a media Block, it looks as though nothing happens - but in fact, the blocks have gone into the work area, but are not displayed. In the poorly recorded video below (watch full screen), the media blocks display because I have logged out of App Inventor and logged back in.

1 Like

I have no problem with it at all, neither with Firefox nor with Chrome (Windows 7 Prof or 10).

Firefox: 95.0.2 (64-Bit)
Chrome: Version 96.0.4664.93 (Offizieller Build) (64-Bit)

No issues here either
Chromium Version 96.0.4664.110 (Official Build) snap (64-bit)

Firefox:

Indeed, but why doesn't it work for everyone? In my case, latest FireFox/latest Chrome on Windows 7, App Inventor is King, superfast FTTP internet - Not a hardware issue.

Interestingly, in my test file, I cannot correctly get the media Block from image1's tray, but Image5's is not a problem (same media Block). Then, having had success via 5, I can go back to 1 and that works too, even though I have clocked-up several fails beforehand in the same session.

I think there is something not quite right with the media Block code - no other Block types fail.

MediaBlockIssue.aia (30.2 KB)

No problems with this either.

TimAI2 & Anke,

Anke, I may be just a tad older, but I trust you and TimAI2 to resolve this problem. It would be great if you keep me informed. Thanks Charles

I can / would only like to solve a problem if I actually have it. But I don't have it.

Hopefully Evan can identify the cause.

Work-around. First, from the tray you want to drag a media block from, drag any non-media block first. Hey presto, the media block will then drag out without issues. @ewpatton, hopefully this is a clue to discovering the root cause of the issue.

This behavior makes the media blocks act like quarks, elementary particles that are seen only as part of another elementary particle.

Maybe this is some kind of validation process, intended to avoid mismatches of Media block type (Screen name/sound file name/image file name) against their target sockets by insisting that there be a compatible target socket open in the Blocks Workspace before the Media block is allowed to appear on the Workspace?

1 Like

That sounds kind of plausible, but the question remains, why does it work for me on all computers / notebooks, browsers, Windows versions etc.

I too am unable to reproduce this problem, so my theory is inappropriate for finding the cause of this error.

As for individual user variations, that leaves:

  • browser extensions
  • web traffic filters from local anti-virus packages
  • transAtlantic latency differences
  • operating system level video driver support (grabbing at straws here)
3 Likes

It presets sound files in image blocks, so it does not differentiate media types.

If any of those were the culprit, surely it would affect other block types as well......

ABG,
Maybe my problem is latency. My computer is in California, but I have no idea where your servers are!
Charles :question:

Here's another hypothesis to try ...

  • How old is your mouse/trackball/touchpad? Is it acting like an amusement park claw machine, dropping its drags before they reach their intended pane? Does the distance to drag affect the problem frequency? Do different components' locations in their pallete extend their drag distance requirements?
3 Likes

All,
Probably another problem... but about six months ago
dragging blocks at first were not be visible, but visible again at the click point. I figured this was an AI2 enhancement, but the block dragging fix occasionally (rare) returns to the old visibility approach. Seems unusual!