Application hangs while importing (object) using 'Previous' and 'Next'

[imrosie]

Hello,

I have a app that allows for searching of images by stored (links) name.
The absolute path to the images is what's stored. Not the image.
Located at the bottom of the form is a previous and next. Sometimes (not always) when an end-user is searching through, a little box (which always
pops up between images displaying the actual import of the full

absolute path) just sits there and hangs.
You can hit 'cancel' on that box till you green, it won't go away. It
sits there in the middle of the form until you close the database
from Task Manager. Very annoying.

At first I thought it was because that particular image wasn't
available, but that's not the case. I can do a Browse to the folder
where image came from just fine....So something else is going
on. Does anyone (I'm sure there are many ones ) have a clue???
Thanks in advance.

Rosie

[NeoPa]

You have (accidentally) posted this question in the Access Articles section. This is NOT an article.
I'm moving this to the main Access questions forum.

MODERATOR.

[imrosie]

You have (accidentally) posted this question in the Access Articles section. This is NOT an article.
I'm moving this to the main Access questions forum.

MODERATOR.

So sorry NeoPa...

Rosie

[NeoPa]

Don't worry Rosie - you're not the first (doubt you'll be the last either) ;)

In your explanation you don't say how the Previous & Next buttons work.
It may be an outside problem, but if it's within Access we'd need to understand what they are doing. It might be a good idea to post the code for the two buttons (I can't promise anything mind - but we can look at least).

Does this only happen when going one way (Only if you use Next or only Previous)?

[missinglinq]

I've seen this problem posted a number of times before and have never seen a satisfactory resolution to it. The cause usually comes down to the user repeatedly changing images without giving Access time to load each one. The simple fact is that Access doesn't handle images well, and is not a very good choice for this type of application. Sorry!

[imrosie]

I've seen this problem posted a number of times before and have never seen a satisfactory resolution to it. The cause usually comes down to the user repeatedly changing images without giving Access time to load each one. The simple fact is that Access doesn't handle images well, and is not a very good choice for this type of application. Sorry!

I was suspicious that was the case....Any suggestions.... ??

Rosie

[imrosie]

Don't worry Rosie - you're not the first (doubt you'll be the last either) ;)

In your explanation you don't say how the Previous & Next buttons work.
It may be an outside problem, but if it's within Access we'd need to understand what they are doing. It might be a good idea to post the code for the two buttons (I can't promise anything mind - but we can look at least).

Does this only happen when going one way (Only if you use Next or only Previous)?

NeoPa,

I notice it when moving forward. I haven't seen it when doing a 'previous'...I' 'm guessing (in my limited knowledge) that it may be happening when there are too many clicks to move forward. Clicks in a rapid succession, thus not allowing Access to fully load the image from the 1st click...

Any ideas or suggestions are certainly welcome. thanks

Rosie

[NeoPa]

NeoPa,

I notice it when moving forward. I haven't seen it when doing a 'previous'...I' 'm guessing (in my limited knowledge) that it may be happening when there are too many clicks to move forward. Clicks in a rapid succession, thus not allowing Access to fully load the image from the 1st click...

Any ideas or suggestions are certainly welcome. thanks

Rosie

As I said in post #4 (which you quoted) :

It might be a good idea to post the code for the two buttons (I can't promise anything mind - but we can look at least).

After Linq's comments I can see what may be happening, but without the code I'm guessing in the dark.

[imrosie]

As I said in post #4 (which you quoted) :

After Linq's comments I can see what may be happening, but without the code I'm guessing in the dark.

You're right...I don't want you in the dark...sorry (working on too many projects at the same time)...it was an oversight on my part. Here is the code and thanks again:

Previous:

Private Sub cmdPrev_Click()
On Error GoTo Err_cmdPrev_Click
 DoCmd.GoToRecord , , acPrevious

Forms!frmimageInventory!frmimagesubform![imgPicture].Height = OrigHght
Forms!frmimageInventory!frmimagesubform![imgPicture].Width = OrigWdth

Exit_cmdPrev_Click:
    Exit Sub

Err_cmdPrev_Click:
    MsgBox Err.Description
    Resume Exit_cmdPrev_Click
    
End Sub

Next:

Private Sub cmdNext_Click()
On Error GoTo Err_cmdNext_Click
    DoCmd.GoToRecord , , acNext

Forms!frmimageInventory!frmimagesubform![imgPicture].Height = OrigHght
Forms!frmimageInventory!frmimagesubform![imgPicture].Width = OrigWdth

Exit_cmdNext_Click:
    Exit Sub

Err_cmdNext_Click:
    MsgBox Err.Description
    Resume Exit_cmdNext_Click
End Sub

Please help....thanks
Rosie

[NeoPa]

NeoPa,

I notice it when moving forward. I haven't seen it when doing a 'previous'...I' 'm guessing (in my limited knowledge) that it may be happening when there are too many clicks to move forward. Clicks in a rapid succession, thus not allowing Access to fully load the image from the 1st click...

Any ideas or suggestions are certainly welcome. thanks

Rosie

I think this post (#7) is basically the explanation of the situation.
Access (or Windows more likely) can store up the mouse clicks even while the code is busy trying to execute earlier clicks. Access is very poor at returning visual updates to the operator (or even when requested, by the O/S) so it often gives the impression that it has hung irrevocably when really it is simply busy. I suspect that, given a longer wait, it would have returned to you after locking up when it did. Next time try using Ctrl-Break (Pause key) and see if it responds. It may well not but it's worth a try. I looked at your code and it seems the only issue likely to cause this is the file accesses to get the images. Cumulatively, they can very possibly cause this issue.
Please understand, I cannot warrant this answer. It may be entirely wrong, but it's my best understanding. If it were my problem that's what I'd assume is the problem to get around.

Try implementing Next and Previous routines which simply get the name of the item, and wait for another CommandButton to be pressed before committing the choice to the screen. Does that make sense?

[ADezii]

Hello,

I have a app that allows for searching of images by stored (links) name.
The absolute path to the images is what's stored. Not the image.
Located at the bottom of the form is a previous and next. Sometimes (not always) when an end-user is searching through, a little box (which always
pops up between images displaying the actual import of the full

absolute path) just sits there and hangs.
You can hit 'cancel' on that box till you green, it won't go away. It
sits there in the middle of the form until you close the database
from Task Manager. Very annoying.

At first I thought it was because that particular image wasn't
available, but that's not the case. I can do a Browse to the folder
where image came from just fine....So something else is going
on. Does anyone (I'm sure there are many ones ) have a clue???
Thanks in advance.

Rosie

I had a very similar problem in which I dynamically loaded a large number of inventory graphic images (*.jpg) into an Image Control in the Form's Current() Event. Believe it or not, I solved the problem by converting the *.jpgs to *.bmps. Are you using *.jpgs - if so convert a couple to *.bmps and see what happens.

[imrosie]

I think this post (#7) is basically the explanation of the situation.
Access (or Windows more likely) can store up the mouse clicks even while the code is busy trying to execute earlier clicks. Access is very poor at returning visual updates to the operator (or even when requested, by the O/S) so it often gives the impression that it has hung irrevocably when really it is simply busy. I suspect that, given a longer wait, it would have returned to you after locking up when it did. Next time try using Ctrl-Break (Pause key) and see if it responds. It may well not but it's worth a try. I looked at your code and it seems the only issue likely to cause this is the file accesses to get the images. Cumulatively, they can very possibly cause this issue.
Please understand, I cannot warrant this answer. It may be entirely wrong, but it's my best understanding. If it were my problem that's what I'd assume is the problem to get around.

Try implementing Next and Previous routines which simply get the name of the item, and wait for another CommandButton to be pressed before committing the choice to the screen. Does that make sense?

I think I follow your logic. break each of the commands....Nex t and Previous into a 2-step process each??? so when a user clicks Next (or Previous?) the command will first display(?) name of the image, then a second user click will actually load(?) the image.....

If that's what you're suggesting wouldn't the image already be loaded in the case of previous? Thanks

Rosie

[NeoPa]

I think I follow your logic. break each of the commands....Nex t and Previous into a 2-step process each??? so when a user clicks Next (or Previous?) the command will first display(?) name of the image, then a second user click will actually load(?) the image.....

If that's what you're suggesting wouldn't the image already be loaded in the case of previous? Thanks

Rosie

Possibly, but then you're relying on the caching.
Personally, to keep the interface consistent, I'd do them both the same. It's also safer that way.

[imrosie]

Possibly, but then you're relying on the caching.
Personally, to keep the interface consistent, I'd do them both the same. It's also safer that way.

I'm going to figure out how to code this. thanks

Rosie

[NeoPa]

Good luck.
You know we're here if you need us.