Too Many Controls...Workaround Ideas?

I don’t know which version of my sample you are using but I would recommend the one in post #17. You appear to have turned Option Explicit off for some reason and there are a few other bugs.

Can you please add your table and code to that sample and upload it in Access 2003 or an earlier version?

Regards,
Chris.
 
I don’t know which version of my sample you are using but I would recommend the one in post #17. You appear to have turned Option Explicit off for some reason and there are a few other bugs.

Can you please add your table and code to that sample and upload it in Access 2003 or an earlier version?

Regards,
Chris.


It would be the last sample - I'm uploading an db now. Option Explicit is still there I just missed it in the copy/paste....appreciate all your input :)


I'm thinking that converting the x values from the main form dates is over the top...but it's hard to work out conflicts in any way without a loop which i suspect kills the mouse...

Oh, and I did have the form neat like you did but it got saved in layout space by mistake! So know design mode is stuck like that. Doesn't seem to make a lot of difference fortunately.

Also couldn't get this under 4.6 meg so had to zip it!


Thanks again, and great to see another Aussie on here :)
 

Attachments

frmSampleForecasting is corrupted and I can’t open it in design mode or recover from it.

It appears you are using Windows 7 so there may be some special Control properties which XP does not like.

Do you have another sample?

Chris.
 
frmSampleForecasting is corrupted and I can’t open it in design mode or recover from it.

It appears you are using Windows 7 so there may be some special Control properties which XP does not like.

Do you have another sample?

Chris.

Annoying!! seems to open just fine form me! arrrg. Even working out of design mode :/


I THINK it's a references issue :( I'm using 2010 and make calls to the Office 14 library...any idea how to get around that for xp? It won't let me remove them due to dependencies...
 
Ok admittedly this is an act of desperation, but I've converted it back to 2000 format, removed the form from start up and copied all the code from the form to a separate module that isn't called but you could copy/paste back into the form...

I think it's the DAO references if so I suspect I have to remove them and get rid of the references...
 
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.
 
Loading and saving is working ok actually, and yeah I was starting to think a cleanup in the MouseUp made more sense than trying to do it in real time!

Having said that I'll get this cleaned up so it'll upload for you.

I'm not actually grouping controls on the form so it's more likely something else, but I'll strip it till it works.
 
>>but I'll strip it till it works.<<

Yep, that's the way it goes; "if in doubt… leave it out" ;)

Chris.
 
Ok, I stripped out everything I could find, removed any references that weren't in the one you sent me when I opened it...I have this fear that access 2010 AUTO adds references looking at them :/ having said that the DAO objects are gone and replaced with sql calls like you use so it SHOULD all be kosher, and the image class is reset with no grid so a much smaller file as well :).

If this one won't open I'll try rebuilding the form from scratch though it looks ok here.

Thanks!

edit: oh, screen resolution at 1280x1024 btw
 

Attachments

Last edited:
Much closer but I still get an error in Form frmSampleForecasting:-

attachment.php



I don’t think it is causing a problem but we don’t know at the moment. It needs to be clean.

There is still a non-essential reference listed which should be removed from the sample. It’s just not needed.

What screen resolution are you using and do you need it that high?

Chris.
 

Attachments

  • CarlOrDavid.PNG
    CarlOrDavid.PNG
    7.5 KB · Views: 298
Much closer but I still get an error in Form frmSampleForecasting:-

attachment.php



I don’t think it is causing a problem but we don’t know at the moment. It needs to be clean.

There is still a non-essential reference listed which should be removed from the sample. It’s just not needed.

What screen resolution are you using and do you need it that high?

Chris.
Resolution is 1280x1024 - we do a lot of spreadsheet style forecasting that drives the resolution. Frankly it's as management insists. I keep trying to explain that throwing up too much information at once is bad for the user, I'm ignored.

I DID miss one removable reference in the last round *my bad* I swear I thought I got them all.

However it won't let me un-check:

Visual Basic For Applications
Microsoft Access 14.0 Object Library

Both of which were in the databases I received from you, OR 2010 access auto inserts them...

I would think the VBA reference would be essential, and the object library:

"One of the most fundamental objects in the Microsoft Access Object Library is named DBEngine. Everything that exists in your database comes directly or indirectly from this object. Because this object is static (it does not change) and is automatically available when you start a new database (it is one of the default objects of the application), you do not need to declare a variable for it. If you want to use it, simply type its name and it is available."

So I assume that doesn't go either, but I'm stressing you version of access uses an earlier reference object. Maybe I just need to get a copy of 2003 and rebuild it there...
 

Attachments

>>However it won't let me un-check:<<
Blah
Blah
If you can’t un-check them there is no point in trying.
They are necessary in Access and we couldn’t even run without them.

On the other hand, the DAO reference can be removed.
Since Access 2000, when the default DAO reference was removed due to an ill-advised push (by Microsoft) to ADO, Microsoft has included a hidden reference to DAO.

In the help file on CurrentDb after version 97 of Access:-
>>Remarks
Note In Microsoft Access the CurrentDb method establishes a hidden reference to the Microsoft DAO 3.6 Object Library in a Microsoft Access database (.mdb).<<

And that is what we are using; the hidden reference to the Microsoft DAO 3.6 Object Library as created by Microsoft.

It was important when versions progressed (?) from version 97 to version 2000 and it has become important again when moving from Access 2010 or Access 2007 back to Access 2003 or earlier. What it actually boils down to is the late binding on the version and the location of the DAO reference. The version may be the same but the location may have changed. So while going up in a version may accommodate the change in location, going back in a version may not. Hence the non-dependency on a hard coded location of the DAO reference and the use of the hidden reference which Microsoft has supplied.

In essence then, for portability between versions, we use late binding for everything and that includes the reference to DAO. (There are known limitations to that but we are not even close to any one of those limits.)


Chris.
 
Ok a lot to go through on that :)

" The version may be the same but the location may have changed. So while going up in a version may accommodate the change in location, going back in a version may not."

Wait, does that mean rebuilding it in 2003 will not necessarily help?

:banghead:

I'll probably give it a shot tonight when i get home anyway...
if there is something in DAO that isn't late bound I don't see it, the only use it gets in the direct sql call

With CurrentDb.OpenRecordset(" Select *" & _
" From " & UseTable & _
" Where MachineTypeFK = '" & MachineType & "'")


all are like that now....

I assume the last upload didn't work either....(it's implied, I know.... :))

Anyway I'll smash my head against it tonight and see if I can think of anything else to make it compatible.

Have a good night!
 
The references are fine in the download from post #32.

However, I still get the error on opening Form frmSampleForecasting as mentioned in post #31.

Chris.
 
The references are fine in the download from post #32.

However, I still get the error on opening Form frmSampleForecasting as mentioned in post #31.

Chris.
Ok I uninstalled 2010
re-installed 2003.
Now I think about it I never used 2003 access. I used 2000 and 2007 2010 (heck even back to dos...), but at 2003 I was home with the kids for a bit :).

I did get errors but seem to have them purged leaving us a format to go back and forth on. If the error persists I'll be in early tomorrow and probably just rebuild the darn thing anyway...frankly the way the main form controls saved in layout space ticks me off and seems finally a good justification for disabling that mode in future.

Interestingly, the performance of the mouse on 2003 is AMAZING. could barely notice any drop in response with 2 bars working... for that alone I could nearly downgrade the whole office but no way is that going to fly with anyone. Nonetheless broke my heart. I might have gotten real time mouse move events working moderately in 2003, no way 2010. it's just to overburdened. :( I'll just have to clean up after mouse up.
 

Attachments

Clean transfer at this end.

I’ll have a closer look at it in the morning. The code in the Class module needs a bit of a clean up to remove the absolute references to the Forms and perhaps a few other things.

Progress… :)

Chris.
 
There is another version attached.

I mainly wanted to get the Forms sized as well as I could but haven’t looked too much at the Class module.

At this stage it might be an idea to see how it works in both Access 2003 and Access 2010.

Chris.
 

Attachments

Forget the download in post #39, I broke the horizontal sizing. :o

Chris.
 

Users who are viewing this thread

Back
Top Bottom