Recent content by tommyboy

This was the answer it seems. Seems obvious now I fully understand how version 2305 fixed special keys. Thanks to all who contributed.

Hi. Thanks for the reply. This is and always has been, set for 'break on unhandled errors'. Cheers

I guess I can just put 'on error resume next' to stop them popping up and confusing people, but that still does not address why they are suddenly appearing after a decade plus of being suppressed on standard start-up of the application. Cheers for the help/advice though. Much appreciated. Tom

Hi, I don't think I am explaining very well... The errors are known errors that are basically irrelevant to my application, but the messages they generate were being supressed before and now they are not and that is what I am trying to understand. I went years without even realising there was...

Thanks for the reply. The default for this application was always special keys disabled (for exactly this reason I imagine). I have updated access to the very latest version, but still the same problem. But I can toggle the special keys setting on/off with v2304 and get the program to run...

So, I finally have some extra info to add to this, although not sure I actually understand what is going on.... I found this old thread that sounded almost exactly like my problem and did some investigation into enabling/disabling special keys...

Hi This is the code I have found runs only double clicking to open the application, rather than bypassing startup. Function InitializeOutlook() As Boolean ' This function is used to initialize the Application and ' NameSpace variables. On Error GoTo HandleErr Set molApp =...

Many thanks. I will investigate.

Do you know where I might find the start up code please? There has to be something that is only triggered on opening the application in the 'uniform' way and has always caused these errors to be ignored up until now, but I do not know where to find it. I know how to investigate these things to...

I am really confused now. If I bypass the start up options on my application (holding down shift when opening), then the form/code in question generates the runtime error in all versions of access I have loaded on my machines. But if I open the application as it is designed to be opened (only...

If you PM me, then I could send you the database and instructions.

holder = Me![Dam] This is the line that generates the error. I currently have two builds running side by side on different machines. On 2304 - 16327.20248, this does not happen. On 2306 - 16529.20064 this does happen. Nothing else has changed.

The original settings in the table design view, were 'Required' - No and 'Allow zero length' - No Have never been changed and never caused a problem with the runtime error until the latest update. I have gone back to the old version now and all is fine again.

It is interesting that the 3024 runtime error also should in theory always have been triggered, as the file name created by the code in question is not and has never been valid (it does not need to be, but that is by the by). Yet, it was never flagged in a decade until this latest build...

I did not write it at all!! I am not an access expert, I just understand a few basics. I have inherited an old group of programs that have worked perfectly for years and so I was curious as to why these runtime errors were suddenly being generated and I know my way around the backends to...