chsoel
2013-11-25T13:59:57Z
Hello :)

I have recently taken on the development of a database that include the iGrid control (V: 5.0.0.50).

The control is used heavily within the database and on random occasions when entering Design View on a form I will receive the classic error 97.

The only other controls on the form are standard access controls, all of which (including the igrid) are nested within a tab control. (I have however had the same issue on a form without the tab control).

Consequently whenever this error occurs i have to revert to an earlier version of the Database to be able to continue working.

This is happening more and more frequently and is starting to become a nuisance.


Any Suggestions?


Alan
Igor/10Tec
2013-11-26T10:17:35Z
This problem was reported 2 or 3 times. It seems that an MS Access form with iGrid may become corrupted after some actions, and this error appears after that. One of the possible reasons - abnormal program termination (for instance, if there was a error in code and the developer hit the End button). Perhaps, some resources of the form aren't closed properly because of a bug in the MS Access development environment, and this leads to the error.

The only known effective solution of this problem is to recreate the form.
chsoel
2013-11-26T11:00:13Z
Hello Igor,

Cheers for that, I was hoping that was not the case. But at least now I know to keep regular backups!


Regards

Alan
Oliver
2013-11-28T09:39:17Z
Hello chsoel

I ran into similar problems with other ActiveX Controls, too so this seems more related to Access than iGrid.

To save your work in this dire situation and replace the corrupt iGrid control, you can:
  1. open the VBA-IDE
  2. export the module from the Project-view context menu
  3. open the file in a text-editor and remove the "Begin CustomControl" / "End" block that contains the line 'Class ="iGrid500_10Tec.iGrid"'
    This removes the iGrid from the form, which prevents you from doing it through the GUI
  4. import the file back into your project via the Project-view context-menu
  5. you lose the iGrid control on that form and all the properties you set on it
  6. you can now edit the form again with all your other code-changes intact

If you hit that scenario frequently, I suggest you set any and all properties of the iGrid through code, so you will lose nothing when you have to replace it.

Regards,
Oliver
chsoel
2013-11-28T09:46:33Z
Hello Oliver,

That looks promising as a solution. However I feel I must be being a little thick this morning as when exporting (Select form from project browser, right click, export) I only get a class file with the modules code and not the actual form definition.

Am i missing something?

Also will this allow me to remove one grid if there are many on a form?


Cheers

Al
Oliver
2013-11-29T07:55:42Z
Hello Al

I'm really sorry for the confusion. We really do it a little differently and I always thought the two ways are the same:

We have a script that essentially does


Application.SaveAsText acForm, "History_View", "c:\temp\History_View.form"

for each form. That WILL export the form definition with everything else, akin to a real VB form. After your changes, you can import it again by using:

引用:

Application.LoadFromText acForm, "History_View", "c:\temp\History_View.form"



Take care to omit the leading "Form_" in the names, else it won't find the form.

We use that technique to "decompose" the entire Application (Forms, Reports, Modules, Classes) into files, so we can check them into Source Control (SVN, Git, VSS, whatever...). The functions are undocumented and only visible in the object browser when you enable the "show hidden elements" option. But these are essentially the functions that are used by Microsoft's own VSS plugin, so they aren't going to be removed soon.

My full post on that topic is here:
http://stackoverflow.com...evelopment/211210#211210 

Hope that helps. :)

Regards,
Oliver
Igor/10Tec
2013-11-29T10:08:16Z
Originally Posted by: Oliver 

I ran into similar problems with other ActiveX Controls, too so this seems more related to Access than iGrid.



Oliver, many-many thanks for this post in defense of iGrid!

Finally somebody (not the developer) confirmed that it is a general problem of MS Access but not only our iGrid ActiveX.