Strange error -- cannot "load" form during "writing" stage o

[Devin]

Hi, folks. One of my VB6 applications is doing something very strange.

I've been successfully updating an activeX control, Graphics Server, to the latest version in all my apps. I started out, like the others, by replacing all references to the graph control in the project and form files with the newer versions. This change allowed me to open the project without the error that the form containing the graph control could not be loaded. And, just like the others, I was then able to run the app in debug mode, and everything worked great.

Where this app differs from the others is that when I compile it, something bad happens. As we all know, there are two steps to making the executable in VB. First, is "compiling." That progress bar fills without any errors. Then, when it's half-way through "writing" the executable, it complains that it cannot "load" the form that has the graph control. (The form's error log says that the graph control itself cannot be loaded.) This is certainly an odd time to see such an error (at least I've never seen it, except when opening a project that has an improperly registered control). It's apparently not a fatal errror, though, because if you click OK, it continues building the executable. But, when I try to run the executable, even on the development machine, and I get to the form containing the graph, the whole program just crashes with the generic message, "this program has caused an error and must be closed... sorry for the inconvenience." (XP is so polite, but you'd think it could give a bit more technical information.)

Has anyone ever seen this kind of thing before? I am unable to find a significant difference between this and the working apps, in regard to the graph control, but I feel that the odd timing of the compiler error message must tell us something.

Thanks for any insight you all can offer.

 

[Devin]

I apologize for this bad forum etiquette, but I'm still stuck on this and it's very frustrating, so I'm replying to it to get it back on the first page.

Is there a compiler log or something that I can look at to give me a clue? The problem here is that I just don't know what debugging techniques can be applied to an error such as this. Basically, I've just been perusing the VB files in notepad, looking for potential causes, based on first principles. This brute force approach is not likely to help me anytime soon or ever.

Unfortunately, first principles tell me that once it's compiled and VB only needs to write the executable, there can be no errors beyond file access issues. Perhaps VB is doing more than I suspect while the "writing" progress bar is filling.

One of you vets must have had this error before.

Thanks for your help.

 

[TheVampire]

Does your form actually have the graph control on it, or does it load it dynamically through code?

If it's loading it dynamically, does your project have the "Remove information about unused ActiveX controls" checked in the "Make" tab of the project options?

That's all I can think of off the top of my head.

Robert

 

[Devin]

If I understand correctly, then no, it is not loaded dynamically. It's there in the object-view at design-time. I'm new to VB and ActiveX, and I underestimated its flexibility. I didn't even think you could create ActiveX controls at run-time, but now that I look over some documentation, it seems that this one can be spawned. However, I'm not calling its Create function -- just laying it out on my form at design-time and setting properties at run-time.

So, I guess your theory was that it may have been trying to call the Create function, but since the control (hypothetically) did not start out on the form, that the compiler wasn't prepared for the function call. I think, however, that since I declare that control in my project file, it should be able to dynamically create a graph. Still it's moot, since I have just the one graph, and it starts out on the form.

Interesting idea, though. Thanks.

 

[CajunCenturion]

I think what I might do is unregister the control, and manually remove every reference from the registry that I'm sure applies to this control. Then I would re-register the lastest and greatest version of the control. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Devin]

I'll have to try that, CC. I think that's my best bet, currently. However, the fact that the other 3 very similar projects do not have this problem, indicates that the registration is probably OK. Also, it may be true that this particular development machine never had the older version installed on it since the last time it was stripped and rebuilt. There are certainly no references to the old ver left in the code, but I should double-check the registry, because there could be some confusion at the level of DLLs calling each other.

Find below my most recent correspondence with Graphics Server Inc.. For the reason I state below, I don't think their advice will be helpful.

Thanks, y'all.

-Devin-

PS: Of course, she suggests a reboot, among other things, but I'm well familiar with the rules of IT debugging. 95% of the problems people come to me whining about are solved by either, "connect it, stupid," or "reboot it, stupid."

PPS: These are closely related to the rules of electronics debugging: (#1) make sure it's plugged in, (#2) make sure it's turned on, and (#3) smack it around a bit.


------------

Lana,

The odd thing is that the control only exists on the form in the sense that there is that hidden control declaration at the top of the form file with the key and default properties, that you can see in notepad. I copied that declaration directly from the one that works. Would removing and replacing the control, as you suggest, do anything but delete and recreate that declaration?

I have read that article, and it served me quite well for 3 of my 4 apps. For some reason this last one is giving me trouble, even though it's almost exactly the same form -- virtually character for character -- that is used in the other 3 projects.

Devin


----- Original Message -----
From: &quot;Lana Ling&quot; <Support@GraphicsServer.com>
To: &quot;Devin Johns&quot; <devin@gaumard.com>; &quot;Lana Ling&quot; <Support@GraphicsServer.com>
Sent: Thursday, February 13, 2003 3:15 PM
Subject: RE: problem


> Hi Devin,
>
> First I would suggest to reboot your machine. The article below gives
> details on how to upgrade to GS v6.0:
>

http://www.graphicsserver.com/support/knowledge_base.aspx?kb=GSKB150

>
> You would want to check the class names and file names mentioned in the
> above article. Make sure you are using the correct names.
>
> If this is not the issue, then I would suggest to make a back up copy, then
> delete the Graph Control from the form, and see if you could load the form
> without getting any error messages or not. Then place a new Graph Control
> on the form and see if that works.
>
> If any other questions arise, please let us know.
>
> --Lana--
>

 

[suds321]

hope this might help. recently we ran into a simliar problem. during the &quot;writing exe&quot; vb6 performed an illegal operation and would not create a new exe file. we determined that one of the controls was causing a problem (comctl32.ocx). if we changed any code on that form and tried to save we got the same vb6 error. our only resolution was to recreate the form again. it seemed to have to do with the binary form file that goes along with your form file (.frm and .frx)

 

[Devin]

Thanks, suds.

Very interesting. I have a new observation. If I open the object view of the form in a window (manually &quot;load&quot; it into VB) before I start Make, then I do not get an error during Writing, and the executable works fine.

I have also noticed that if I get the error once and then try to work with that control without a reboot, like creating a new instance, then I get this thing I've never seen before, simply: &quot;System error <some hex number> <some negative decimal number>&quot; -- no other info, not even a msgbox title. It happens the moment I release the mouse after trying to graphically place the new control. Without a reboot, it seems to have forgotten the basic identity of that control, though it does stay on the toolbar and otherwise seems to be available.

I am glad you raised the .frx issue, because I have been wondering about something that relates to those files. Sometimes I try to reuse a form and make a copy of the .frm file. But, all the button images on that form get lost. If you look in the form file, the picture property is just specified with some address and the name of the .frx file. And, even in the original project, if you go to browse for a new image in the properties window, it doesn't start you in the location of the original or tell you a file name. I can't figure out how to uncover the identity of the original picture files. I've of course tried to move the .frx along with the .frm, but that doesn't prevent the button images from getting lost. It seems as though the image gets compiled in and is no longer necessary as a file. That has its advantages, I suppose. In some cases I've had to resort to doing a screen capture from the original program and then cropping out and saving all of the button images. It causes a bit of a color shift but gets the job done. Can anyone explain this?

I will copy the above paragraph as a new thread, if those monitoring this thread don't have something to say on it.