Anyone know VB? Vexing problem...

[Morat20]

For reasons beyond my understanding, I have been tapped to "modify" some exisiting VB code. Because merely being called upon to modify code for a VERY old application that we didn't write (but weaseled the source code out of to make some modifications to back in 1997 or 1998, I believe), it of course has to be in a language that I've never glanced at, even if it has "Basic" in the name.

To make matters worse, this is VB 6.0 code -- we don't have a 6.0 compiler. (We're supposed to, it's on the list, but no one can find it). Meaning I get to "upgrade" the code to a later version of .NET. While Visual Studio is actually pretty solid about that, I lack the expertise to tell when and where it goes off the rails, and have thus been involved in a lengthy process called "poking the results with a stick, fixing it bit by bit".

It runs now, by the way. Not properly, but it runs. Which is pretty awesome, given that -- among other things -- it has classes called "frmKrak" that contain checkboxes called "frmKrak", and the instantion of the class in the code is called "frmKrak" -- which I must say has led to a great deal of confusion on everyone's part. Morons.

Anyhoo, my current problem can be boiled down to (I think!) the fact that "Load()" went bye-bye. I have no idea how this sucker worked under VB 6.0, but I currently have the following problem:

Class "MainGUI", Class "InterestingOptions" and class "OutputWindow" are three classes -- indeed, three seperate GUI windows. MainGUI is kicked off by "SplashScreen" which creates an instance of MainGui and shows it.

Now, the fun part -- MainGUI has two buttons. One button, when clicked, brings up "InterestingOptions". That one is full of checkboxes and dropdowns. When you change one, it changes some stored data. There is no "save", "cancel" or "exit" button. There is only the x button at the top right. Changeing an option kicks off an event in MainGUI that changes some underlying data.

The fun part? Options can be set in "InterestingOptions" by loading an input file. Or by clicking the button marked "Options".

Here's the thing -- where the flying FUCK do I instantate this thing? You know Something myOptionsPane as InterestingOptions?

Because I can't get the goddamn thing to load statically. I can't get it to load globally. I can't even find a relevant method like INITIALIZE() to create it (that's locked off by the WYSIWYG editor). I can declare it "public" as part of MainGUI, which means both the events to bring up the pane can see it...

But I have to instantate it elseswhere -- otherwise I end up with one or the other allocating it. And the second someone hits that "x" button, it disposes of itself. Not hides itself.

Personally, I'd be happy just creating a static copy of it and having it hide and show itself and not get disposed until MainGUI exits. I'd settle for accessing the damn thing where it didn't either complain it wasn't allocated OR complain it's been disposed of.

The code proper -- the VB 6.0 -- seriously acts like this damn thing is global, like the "Load()" command allocated space and everyone could see it -- but that's now how the new and show() stuff is working. The "Output" tab is, by the way, having the same problem. Except -- I shit you not -- it appears as if data is written to the Output BEFORE the Load() statement I replaced. That's for later.

And to top it off, I can't seem to programitcally change the goddamn checkbox states on the InterestingOptions GUI, probably because it's not allocated or allocated twice or already disposed. I can click the boxes and THAT works, but the actual code that's all blah.blah.checkboxstate = checkboxstate.checked? Doesn't do shit.

And get this? All this goddamn work so I can add a single subroutine -- that takes a list of data it prints to a gnuplot file and prints that table up in a seperate file, individually. A five minute job. (Oh, and there's some graphing -- I've had to replace the simple draw primatives in VB6 with the newer ones -- I'm betting those don't work, but I haven't gotten there to test).

So, any clues? It's MainGUI and two subGUIs that can be activated by two or more paths (and thus show up) that can only be closed by the "x" windows button, that I need to NOT lose state unless the program explicitly changes it.

[Krakrok]

I never used VB6 but I have 7+ years with Delphi. Sounds like the window is a modeless window or MDI child. As in it isn't a full form but a subform that gets created by a parent. It's probably auto created by the parent.

When the Close method is called on a Form displayed as a modeless window, you cannot call the Show method to make the form visible, because the form's resources have already been released. To hide a form and then make it visible, use the Control.Hide method.

http://msdn.microsoft.com/en-us/library/system.windows.forms.form.closing.aspx#Y594

Set .cancel = True in the Closing event to keep the options window from closing when you hit the X and have it hide itself instead. Or remove the X button from the Window.

[Morat20]

Hmm. Don't know if you can overload the lovely little x-button, but it's smarter than overloading disposed if I can.

It's that or try to figure out how to make the form truly global in scope. Why couldn't this have been written in C# or something I actually had experience in? Or at least in a language that didn't get a massive rewrite between this getting written and me having to change it.

Thanks. Gives me something to fiddle with at least.

[Morat20]

I had to disable the windows control buttons and add a "close" button. Otherwise, nothing I did would prevent the window from being garbage collected and disposed. Including overloading the on-close method.

I'm gonna have to do that to two more windows. Forms. Whatever they're called. PITA, is what it is.

[Tarami]

Are you sure you're listening to the right event? This is C#, but the semantics should be identical.

Code:

private void MyForm_FormClosing(object sender, FormClosingEventArgs e) {
     e.Cancel = true;
}

This blocks you from closing it in any manual way, the X, Alt+F4 and even form.Close().

[MahrinSkel]

Remember that VB isn't calling any of this stuff directly, it's calling it through the runtime engine, and you can only access what it lets you.  I'm about 15 years since my last VB app, but I remember running into things like this, that would be a one-line fix in a compiled language but were completely inaccessible in VB and required baroque workarounds, all the time.

--Dave

EDIT: Have you considered creating your own VB components (or whatever they call their widgets, I forget)?  I was building bastard half-VB, half Delphi apps all the time back in the day because it was just so much easier to write my new code and fix screwy dialogs in Delphi, then call those DLL's from the VB app.

EDIT2: Before anyone starts screaming: The shop was (slowly) converting all their VB stuff to Delphi.  I was the guy that hacked the VB apps back together when they broke before they were ready to convert, and I figured that having some Delphi in it when they started the conversion couldn't hurt.

[Morat20]

I got it -- more or less -- working. The numbers on the back end are..close enough for jazz. Only thing left really is getting the output window to load properly and some drawing stuff -- .NET 1.1 really overhauled the primative graphics stuff.

At least half the input code simply reads empty strings ("") and converts it to integer -- which doesn't work in .NET. I think it defaulted to 0 in VB, so that's what I'm reworking now.

*Really* not thrilled with this whole state of affairs, but it's what I'm paid for. I just think the time invested versus the payoff is kinda of a waste, but I'm not the guy having to use it. I can't really say if what he wanted (a really, really, simple little change) is worth the effort of me porting this over and adding the change in or not.

[Sheepherder]

Why couldn't this have been written in C# or something I actually had experience in? Or at least in a language that didn't get a massive rewrite between this getting written and me having to change it.

They taught rudimentary VB 6.0 in my high school, the one math teacher they roped into teaching CS loved it.  This is why you shouldn't let math teachers out of their cages.

Option Explicit.  If he's sloppy with naming it's something you should check for.

[Morat20]

Yeah, turned that on really quickly. From what I understand of the VB evolution, there was VB 6.0. Then Microsoft lost a lawsuit over it with Sun. MS's response was to redo VB as .NET 1.1.

Which while not a total overhaul, was a fairly sizeable one -- MS's tools for coversion are good, but a lot of stuff just didn't have 1.1 equviliants. MS also completely stopped supporting 6.0, so I couldn't just snag a 6.0 compiler off their website.

I've almost got it fixed. I've got some string to integer stuff I have to go in and -- line by line -- handle, and then some issues with the graphics primatives that are used, and then it's more or less done and I turn it over to the engineer who wanted it for some sanity checks on the numbers out the back end.

I do appreciate the help. Krakok put me on the ultimate solution.