Decompile code (reorder references). Comments please

[Graeme Richardson]

Hi, a project I'm working on is not destroying instantiated objects as
required. I find that decompiling and then compiling the project fixes the
problem. However, if I then edit [enough] code the problem returns.
Manually reordering the references causes Access/VBA to properly decompile
the entire project so that it can be recompiled and the problem goes away.
Reordering references is tedious so I've written the following sub to do the
job. The code runs in the same project as I'm decompiling.
What are your thoughts?
I'm surprised that I'm able to do this.

Public Sub DecompileCode()
' Decompile code by removing and then re-adding references

Dim ref As Reference
Dim intCount As Integer, intTotal As Integer
Dim strFile As String

intTotal = References.Count
For intCount = 3 To intTotal ' Can't remove first 2 references

Set ref = References(3)

' Store info on reference
strFile = ref.FullPath

'Remove the reference
References.Remove ref

' Restore the reference (to last in list)
Set ref = References.AddFromFile(strFile)

Next

End Sub

Thanks, Graeme

 

[Allen Browne]

Creative idea, Graeme. Reordering the references causes Access to
reinterpret (and therefore decompile) every line of code in the application.

Theoretically, you could achieve the same result with the /decompile command
line switch, by changing the name of the project (on the Tools menu of the
code window), or even importing the code into a different version mdb (since
that creates a different binary).

The more fundamental issue, though, is that your project is constantly
corrupting in this way. Access maintains two copies of your code: the text
version (what you edit) and the compiled version (what executes). If these
two versions get out of sync, you have a corruption, and this is very
common.

When you edit the code behind a form, things get more complex. Access
creates a temporary copy of the object, so it can reinstate the previous
saved copy if you abandon your edits. Presumably it is now trying to
maintain 4 copies of the code: the text and compiled versions of the
original saved version, plus the text version (what you are editing) and
compiled version (what's actually running) of the binary. If you are doing
this while the form is open and running (i.e. not in design view), the
chances of it getting confused between the 4 copies and therefore corrupting
are markedly increased in our experience. The same applies to a class module
that you modify while the object is instantiated. Simply switching the form
to design view or manually destroying the object before editing might help
prevent your corruptions.

If that does not help, the solution may be to trace down why the
instantiated objects are not being destroyed.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

Hi, a project I'm working on is not destroying instantiated objects as
required. I find that decompiling and then compiling the project fixes the
problem. However, if I then edit [enough] code the problem returns.
Manually reordering the references causes Access/VBA to properly decompile
the entire project so that it can be recompiled and the problem goes away.
Reordering references is tedious so I've written the following sub to do the
job. The code runs in the same project as I'm decompiling.
What are your thoughts?
I'm surprised that I'm able to do this.

Public Sub DecompileCode()
' Decompile code by removing and then re-adding references

Dim ref As Reference
Dim intCount As Integer, intTotal As Integer
Dim strFile As String

intTotal = References.Count
For intCount = 3 To intTotal ' Can't remove first 2 references

Set ref = References(3)

' Store info on reference
strFile = ref.FullPath

'Remove the reference
References.Remove ref

' Restore the reference (to last in list)
Set ref = References.AddFromFile(strFile)

Next

End Sub

Thanks, Graeme

 

[Graeme Richardson]

Thanks Allen,
I have a shortcut with the /decompile switch on my desktop. The help files
recommend backing up project before using this option. Takes 2-3 minutes to
complete the procedure.
I tried changing the project name in the Tools > ... Properties . This
didn't decompile the code though (note, I'm using A2K not '97). Before
writing the procedure [last message] I was selecting a random reference and
reordering it to the top (3rd position); accepting ; then opening references
to remove random reference. Renaming the project would prove easier.
I have recreated the container and imported objects a few times. Takes
around 5 minutes [plus re-adding references] so I'm not doing it too often.
[Do you remember the problems with '95 in importing corruptions to the new
container? ]

I like your discussion on how Access creates restore points (4 copies!?!).
Frustrating that it's pointers are getting confused. It's the price that's
paid, I guess, for the ability to edit code that is being executed.

Cheers, Graeme.