onClick error in mde when using runtime

[Guest]

I have an application that using the common dialog control to allow the user to select a picture they wish to insert and store (the path) in the database for use with some reports. This process works just find in my mde file when I am opening it on my machine in Access XP. However, when I install my application and test it using the Access runtime, this same process doesn't work.

Here's the error:
"The expression On Click you entered as the event property setting produced the following error: The operation on the | object failed."

At first I thought this was an mde issue but when the original mde worked I was stumped. The installed version of my application is on my machine as well it's just that the shortcut I'm using is telling the app to open using the runtime. Any suggestions? I really need to get this app ready for sale and now that I've fixed all of my install/uninstall problems, this is my last obstacle.

I have tried decompiling to see if that would do the trick but again, my original mde works and the installed one doesn't.

Thanks for any help!!

 

[Albert D. Kallal]

As most developers know, relaying on the common dialogs, and hoping that the
same library, or same version is on the target pc is a really hanging
oneself by a thread.

It is the general consensus of most elopers that the troubles, and
un-reliably of using the common dialogs is not worth it.

The best approach is to use the api code found here:
http://www.mvps.org/access/api/api0001.htm

I is free for the taking, and I never heard of anyone having any trouble,
and it works on all windows versions, and you don't have to worry about
version problems.

 

[Dirk Goldgar]

It is the general consensus of most elopers that the troubles, and ^^^^^^
un-reliably of using the common dialogs is not worth it.

And here I thought it was rickety ladders that caused the most trouble!
<g,d & r>

 

[Albert D. Kallal]

Yes..and remind me to figure out how to use the spell checker...

In fact..I had bumped the send by accident (using a notebook with a touchy
touch pad).

I figured at this point, I can't get any more embarrassed..so I did not
bother re-post with spelling check.....

 

[Albert D. Kallal]

However, just to satisfy my curiosity and please forgive my ignorance, what
would I want to include in my install package to have this not happen?

By the above do you mean not have a common dialogs problem?

Well, gee, if I had that solution, then why would I suggest to the API
solution?

Fact is, I don't know of a reliable solution using the common dialogs,
so..we just use the api and never have a problem.

We get:
common dialgs = lots of installing and setup problems, and it breaks

or

Rock solid reliable api that never breaks.


Hum...perhaps I not sure of your question? But, if I knew of something to
prevent problems with the common dialogs, then I would not suggested you
dump that approach, and use something more reliable. You have to as a matter
of development process use things that are more reliable, and avoid things
that are not. This is one of the essential qualities of good developers vs
bad one.

Take a quick read of the following idea and concepts I used for a word
merge..and you will understand what I mean by quality by design:

http://www.attcanada.net/~kallal.msn/wordmerge/page2.html

Skip the first part, and start reading at:

"A few more points about this code, and ensuring reliable operation"

 

[Guest]

Hmmm...did I make you angry? I am all for using what really works rather than what is "supposed" to work. Rather than attempt to modify my previous poorly worded question, I'll just stop here with another word of thanks to you for helping me resolve my current issue. Your advice worked like a charm and I will heed your advice about avoiding the common dialogs.