Ralph
7/11/2012 2:10:00 AM
On Tue, 10 Jul 2012 15:13:59 -0700, BeeJ <nospam@spamnot.com> wrote:
>ralph formulated the question :
>> On Mon, 09 Jul 2012 19:33:23 -0700, BeeJ <nospam@spamnot.com> wrote:
>>
>>
>>>
>>> Solved.
>>> For some reason OLEAutomation disappeared from References and another
>>> unwanted reference replaced it. Freaky.
>>>
>>
>> Wow. Talk about lag. Twenty minutes. I checked for other posts before
>> posting.
>>
>> The most common reason for a .VBP file to get confused is by editing
>> or otherwise manipulating VB files outside the VBIDE while it is still
>> open and 'running'.
>>
>> -ralph
>
>Yeah, learning that maybe the MZTools feature of editing as a text file
>may not be such a good idea. Think it was that? Have done that before
>with no problems but ???
No idea, but certainly a possibility.
To be boorish ...
It has been many moons since I played with how VB manages it files.
Our problem domain then was ferreting out various oddities that
occurred while trying to run background repository and management
tools in a multi-project and multiple developer environment - while
they were working.
[The VBIDE merely loads the files, parses them into opcode (pcode),
which also includes multiple dictionaries, tables, and caches. (code
itself is on a stack.) This opcode is delimited or spaced between the
source text, or you can think of the source text as 'comments'. The
VBEditor displays only the 'commented' source lines.]
I went into the project thinking that simple 'race-conditions' was the
only problem. After all, if VB open files and created its own working
cache the only issue when a third-party tool messed with a file in the
meantime would be - who's changes were saved last.
At the time I had access to a good soft-ice tool, so was able to watch
and record everything the VBIDE did or touched. When VB loaded a
project it did exactly as suspected. What was a total surprise (and it
shouldn't have been in hindsight) was to discover the VBIDE is a very
very busy place. (Depending on the complexity of the project of
course) Simply opening or closing a file in the Editor set-off what
can only be called, to my untrained eyes, a rash of wholesale,
willy-nilly, in-memory changes and file writes. Even an occasional
'revisit to original source files.*
The biggest issue was with files immediately (pun intended) open in
the editor. 99% of the time as long as one didn't mess with an open
file (being edited) - you were OK. But even then strange things
happened often enough that we just plain put the kibosh on touching
anything a VB project needs while the VBIDE was open. And peace
returned.
So can you get away with it? Yes. Simply making sure you don't try and
chew on the same animal in two places at the same time is caution
enough. - but expect surprises. <g>
-ralph
[This is compounded by the fact that the VBIDE assumes it is the King
of its Universe. It assumes total ownership of everything in its
current project. He shares poorly - in fact - "sharing" isn't in its
vocabulary. So, is he 'reworking' the code or simply doing an
inventory? <g>
There are a few poorly documented routines that allows outside
applications to signal changes to VB (and vice versa). VB Fusion was
only the commercial editor I used that tried to make full use of that
API. Even then subtle errors would creep in. That did it for me. No
outside editing with an open IDE. But then I always was a coward and
hate going back and fixing things that shouldn't have been broken.
<g>]