I can still not get a reliable download from the upload in post #26.
I get a message that there is one error involving something that Access 2003 does not recognise in Form frmSampleForecasting. It removes all the code from frmSampleForecasting and puts it in a standard module. As such it will not run. Also, Class module clsLabelDDR is still in the database and it is not used. The uploads you make are not ‘cleaned’ of extraneous junk.
We need to keep it to the minimum required to get the job at hand done.
----------
I can get around the reference problem by deleting it and using CurrentDB directly.
(Apart from the two which can not be removed, the original sample I posted does not use any references and I intend to keep it that way.)
But that is not the problem. As far as XP is concerned frmSampleForecasting has been corrupted. Maybe it’s something to do with grouping controls, or whatever they call it in Access 2010, but that sort of thing is not necessary for this part of the project. So, if I’m going to help, we will need to remove all the new ‘features’ of Access 2010 and simply use code to manipulate the standard features of Access 2003.
Also, you have a bitmap image in Form frmDayGridSubform which is not required and is taking up 3 Meg. It’s only a bitmap of a grid and we are drawing the grid over to top of it. The reason we are drawing the grid is to allow easier changing of the number of days and the number of plants shown. So the image of the grid is simply taking up unnecessary space.
You also appear to be using a strange screen resolution; what is it?
By applying too much code too soon I think we may be getting ahead of ourselves here. Better to take it one small step at a time and test that small step. When it’s time to move on, increment the version number and go to the next step. Keep backups of all the previous steps.
Don’t throw away any code you already have, save it for later. But don’t include any code not required for the current step we are working on.
There are things you included in the Class module which need to be fixed and I don’t mind doing that. But it will waste a lot of time if I can not open all of any of your samples.
To me, these are the steps…
1. Proof of data display. That involves the method of displaying the data, saving the data and redisplaying the data on both Form open and when the next batch of Days needs to be displayed. It also involves the table structure in which to hold the data. That table structure may include one but probably at least two tables. That table structure is up to you. Since this is an addition to an existing database the table structure may be incorrect but it could also mean it’s far too late to change. That is your call.
In any case, this new functionality must not interfere with the existing database. It must be stand alone functionality which can be imported into the existing database without interfering with it. As such, the sample databases as posted must use existing data, or additions to the existing data, and therefore must also be stand alone in their own right. In simpler terms, we are making an addition to the existing database not modifying what is already in it. We should be able to import the new functionality, or delete it, without the existing database even knowing about it.
2. Next is Day collision detection.
That comes later but will probably not be done on Mouse Move. You are now aware that the mouse move is happening far too fast to run any sort of extensive code. The collision code will probably need to be laid off until at least the Mouse Up event and before the save of data (maybe), if it is at all necessary. But that is step 2 and we are not out of step 1 as yet.
At the moment, though, the primary consideration is the reliable transfer of sample databases between the parties concerned.
Chris.