Image Picker 'Image access' limitations

I brought this latest post back to this thread.

There is no need to start a new thread here.

I recommend getting a screen session recorder so we can watch a recording of your problem.

Loom.com is good and free for starters.

1 Like

That's symptomatic of a known issue with the new Media Blocks. If you have got an image in your Media List, App Inventor will try to place a block for it in a useful place. Somewhere along the line, this adversely affects the display - so you can click or drag a Media Block or a Block with a Media Block pre-attached, and it will be added to the Project file but not displayed. Logging out of App Inventor, then logging back in, the display is corrected (Note, only works safely if Project Autoload is disabled in Settings).

Does that sound familiar Charles?

1 Like

ChrisWard,
Yes it sure does! Unless recommend otherwise I'll avoid ImagePicker for awhile. Hope this feature's problem is received soon. Thanks Charles

..... unfortunately, it isn't just the Image Picker - any Block that has anything to do with files in the Media tray can exhibit the same problem. I just hit the issue with an Image Sprite.

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.