Question Making changes to MsysResource table. (1 Viewer)

I have noticed that when I add / update (not sure exactly what triggers this) an image to the Access Image Gallery and then put it on a form then upon the next time the form is opened I get

"The OpenForm action was canceled. Error No. 2501"

Click to expand...

I then worked out if I open the form > open the VBE > Debug > Compile, then Compact and Repair twice the form opens again without error.

Is this something know to others?

My extended question here is that I also had a little look at the MSysResource table and manually changed a name. This too resulted in an error when opening the form but went away when I Compiled, Repaired as indicated above.

My understanding is that the Name column in MSysResouces is a key which is used by Access to get the image.

I am sure you want to write "Don't touch the system tables" and I would like to do this, however, I am thinking about the following;

I am thinking of making my icons themed. For example I have added to the Image Gallery two icons which are identical except that one is black and the other is white.

eg. wh_MyIcon and bl_MyIcon (being the names of the images in the Table)

A control on a form points to the Shared image wh_MyIcon. Now I thought I could be smart and in the MSysResouces table if I got these two rows and changed the Name in the row with wh_MyIcon to something else and the name in the row with bl_MyIcon to wh_MyIcon then now when the control on the form looks for wh_MyIcon it will actually get the black icon.

I have tested this and it works except for the problem I mentioned above also happens, in that the form does not open properly after the change. This would not be suitable when the form is being used by a user.

I am aware I could load the images on the fly from files, I'm also aware that I could loop through all image controls on a form and change the Picture property from wh_MyIcon to bl_MyIcon however both these things require extra code to be added to the Open event of a form and have to run every time. The above table changes means no extra work after of course the table has been changed.

Heck, anything could possibly work if you were careful enough, but using action queries on the MSys tables is not generally considered to be a good idea.

Your understanding of the use of the Name column in MSysResources might well be correct, but I wonder what would happen if you are wrong? We cannot forget that Access does things with all MSys tables "behind the scenes" AND has the right to change the way those things work if they want/need to do so. To directly modify such tables can be a crapshoot at best and nuclear armageddon (on a small scale) at worst. The question in my mind is what else has to be done simultaneously with your update of your chosen table. I.e. what are the side effects?

Before you do something so massively dangerous, I would reconsider. And make GOOD backup copies just in case one of your changes has the effect of nuking your app.

Stated another way, when I was a software engineer for one of my employers many years ago, we made estimates of how difficult to be if we expected certain projects. The marketing guys could then figure an approximate price point. On our scale, what you propose is one of the "extremely high risk of requiring complex code" categories.

The_Doc_Man said:

Heck, anything could possibly work if you were careful enough, but using action queries on the MSys tables is not generally considered to be a good idea.

Click to expand...

Yeh I know. I would love to know however why the form open event gets messed up anyway.

As to the MSysResource table I will give up on this very easily. I am for example just testing doing all the changes in the forms open event.

Here's a different thought. If you are trying to do "themed" stuff, are you aware that you can define your object appearance to be consistent with your user's chosen Windows theme? Look up "Windows system colors" as a topic.

If you have a convenient code window open, you can also open Object Browser and see if you can find (under the VBA library) SystemColorConstants. If you apply those constants to your objects in their ForeColor, BackColor, and BorderColor properties, then your app comes up looking like it was integrated into Windows itself.