This isn't strictly speaking a programming problem, though the solution may well involve some minor coding in VBA. I am posting it here because I trust several of the people here, and because when I've posted it to Access-specific forums like Utter Access, it got lost in the noise.
I have a two-table database and a data entry form which I created for a client in Access 2K, a very simple layout consisting of a title, a bound OLE image control, and a tabbed group containing about fifteen simple bound text controls and one combo box control. I am having a few problems, which are all the more puzzling since they only occur on the client's system - I haven't been able to reproduce them on my development box. While I haven't ruled out the possibility that they are due to configuration problems on the system itself, I would rather see if they occur elsewhere, and see what the solution is.
The first problem, not surprisingly, has to do with the image control. Now, in researching the problem, I found three different ways to bind an image to the database. I used the simplest solution, namely a simple bound OLE image control, primarily because a) it was the simplest approach, and I was under a tight time schedule, and b) because, unlike the other two approaches (storing a hyperlink to the image and then displaying it at run time with an external viewer, or else storing the image file as a BLOB and then doing same), it would allow the user to cut and paste the image to the control, which they had specifically requested the program do. There had been warnings about problems with this approach, and I did have some problem with it in development (it would save images copied from the web browser, but not from MS Paint or Photoshop), but I was able to get it working consistently as long as I used the same method to copy the images. However, when I installed a copy on the user's machine, it wouldn't paste anything.
(As an aside, I should mention that it doesn't support the alt-click menu for pasting - to paste something, you have to select the image control and then either choose paste from the menu, or else use crtl-v; this is what I as an Access developer knew would happen, but it was a bit confusing to the client, as it happens.)
The other problem arose when the user went to enter some data: he found that, when he tabbed from the first to the second tabbed section, the program would freeze up entirely, and the process had to be killed. I had not experienced anything of this sort on my own machine. Since the client's computer is several years newer, and presumably is faster and has more memory than mine (shame on me); I would have to get the details from him to be certain.
Both my machine and his are running XP, though I have my UI set to the older Windows 98 style rather than the Kandy-Kolor XP style. The user's machine also uses large fonts and icons set (both he and his wife have some vision problems), and he mentioned that there might have been some Registry problems; the system certainly felt sluggish overall.
Any suggestions? Since the latter isn't necessarily an Access issue, I am mostly looking for help on the image issues, esp. any help on a more efficient and less problematic solution that still allows the user to cut-and-paste or drag-and-drop the image rather than browse for the file name.
Problems with an Access form
Re:Problems with an Access form
As far as I can tell:
You have a problem using a default action in windows controls, using plain controls (the tab problem). This only happens on a PC you don't trust (is sluggish although it has better hardware).
You seem to be unable to use a default action on a default control (the paint problem this time, although you do have a little added code with the control (I assume, the paint operation probably won't be standard). This again happens on the nontrusted PC.
My guess is that the target computer has a sort of software that makes the standard controls unreliable, IE, replaces them with a different version. This can be intentional nonharmful (new program, different semantics, although it shouldn't happen), intentional harmful (virus?) or unintentional nonharmful (if you don't intend to do harm, you won't, type like a bad sector on the harddisk causing the program to not be corrupt, but just unreliable).
You have a problem using a default action in windows controls, using plain controls (the tab problem). This only happens on a PC you don't trust (is sluggish although it has better hardware).
You seem to be unable to use a default action on a default control (the paint problem this time, although you do have a little added code with the control (I assume, the paint operation probably won't be standard). This again happens on the nontrusted PC.
My guess is that the target computer has a sort of software that makes the standard controls unreliable, IE, replaces them with a different version. This can be intentional nonharmful (new program, different semantics, although it shouldn't happen), intentional harmful (virus?) or unintentional nonharmful (if you don't intend to do harm, you won't, type like a bad sector on the harddisk causing the program to not be corrupt, but just unreliable).