Results 1 to 9 of 9

Thread: Ugh - Visual Basic "fun"

  1. #1

    Ugh - Visual Basic "fun"

    First of all, I apologise for asking a Visual Basic question here . It's really not my choice to use this damned thing, sigh. VB is such a pile of crap compared to Delphi. Anyway, here's my problem...

    I've been asked to write an ActiveX control for an existing system. The ActiveX DLL I'll be writing is an extension to this system. The user (a GP) will search for patients and then select one from a list. When they select a patient, a separate window appears with a tabbed control (dunno whether it's an old tab control, page control, or whatever at the moment). The ActiveX control will be found by the system and will appear as a separate tab on this window.

    I have to chuck a web browser onto this separate tab so that the user has access to a browser within the system. It'll have to deal with authentication and other nonsense, but that's in the future.

    The above is fine, I think. The people writing the system gave me an example project that seems to add a blank tab fine. The trouble is that this doesn't work very nicely when I add stuff to it .

    At the moment I want (no, I need) a webbrowser component (in "Microsoft Internet Controls", shdocvw.dll I think) for what I have to do later. I've managed to create this in code (using the wonderful syntax "set webby = controls.add("Shell.Explorer.2", "webby")". The thing displays and it appears to work, except that the system gives a runtime error 216 when closing down. This error _only happens_ when I try to use the damned web browser (e.g."webby.navigate("http://www.whereever.com").

    I've narrowed it down slightly. If I don't select anything on the tab then it's okay -- as long as the focus stays on the tab itself. If I select text in a textbox with the mouse and close the window, I get an access violation and then the program immediately vanishes (due to vb's extemely brittle nature). If I select the web browser, or use its .navigate method, then it seems to work... except that it gives a runtime error 216 when the program is closed for good (not immediately in other words).

    AAAAAAAARRRRGGGHHH! I hate VB more than ever - it's so f'cking limiting. Yuck.

    Anyway, does anyone have experience with ActiveX controls and/or the web browser component in vb? Can anyone solve the mystery of why it falls over so readily?
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  2. #2

    Ugh - Visual Basic "fun"

    A small update: there are ok and cancel buttons on the relevant form to contain the new tab. However, the creators of the system left the default "x" button at the window top-right too. The access violation only occurs when the x button is clicked (which is actually pretty likely, since that's the standard way to close most windows) but not when the ok or cance/l buttons are used. Thus, I feel more confident -- that kind of badness (forgetting to remove the x button from a window where necessary) implies that this may not be me messing up but the people who wrote the system. Although I'm probably still doing something wrong.

    So, the question is now: why is the program giving me a runtime 216 error if I use a webbrowser component? I know that 216 errors sometimes happen in Delphi-written programs when *I think* an exception is raised in the finalization section where the default exception handler isn't around any more. Uh, something like that.

    Someone must have used the pain that is VB - any idea about the 216 error?
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  3. #3

    Ugh - Visual Basic "fun"

    Hi

    Just a thought but try http://forum.pcplus.co.uk/. I have often found the solution to a problem I have had with Delphi. There is also a VB and C++ forum.

  4. #4

    Ugh - Visual Basic "fun"

    So wait...

    you only get a 216 error if you use the web-browser and then exit the window with the x right? But closing out using OK or CANCEL everything is okay. And if you close via the x without using the web-browser everything is okay too.

    If that is what's happening, let me know. I'll look into it. I used to program VB for 5-6 years at my previous job (the hell that is was).



    P.S. What version of VB are you using?

    P.P.S. Are you destroying the dynamically created web-browser upon exit?
    My DGDev forum pascal syntax highlight settings:
    <br />[background=#FFFFFF][comment=#8080FF][normal=#000080]
    <br />[number=#C00000][reserved=#000000][string=#00C000]

  5. #5

    Ugh - Visual Basic "fun"

    Ah, merci beaucoup Xorcist. Here's the situation:

    First of all, I'm using Visual Basic 6 with service pack 5.

    There are _two_ problems at the moment that are reasonably unrelated.

    * Any control that can have focus (buttons, textboxes and the like) are flaky -- if focused and I close with the x button (top-right, standard Windows close button in the caption bar) then kaboom! This is reproducible by placing a single button anywhere on the control at design time, not even supplying code for it! This is most definitely the fault of the people who wrote the software -- it doesn't happen if I use their own ok/cancel buttons. Basically, I think they totally forgot about the x button (hell, it's only one or two clicks to remove it from the title bar, so it takes spectacular carelessness to forget!). This is probably the case in other sections of the software, though I've not checked.

    I think that the above isn't too important -- I've already raised a call to their help desk so they know about it. It'll get fixed in time and seems like a programming error that will be fixed or is fixed already (I found out on Friday that we don't have the latest version of the software).

    * The web browser problem is where I'm interested in your opinion

    Basically, I can't use the web browser, which is pretty annoying. It seems that I can't use its Navigate or Navigate2 methods.

    The project I'm working on is yer standard ActiveX control, which implements some-interface-or-other required for communicating to the main software (not relevant to this problem, I believe). It's an example project written by the people who wrote the original system, so I'm moderately confident that it doesn't have any problems. I hope!

    I can place a web browser onto the empty ActiveX object, do some registry voodoo, and the thing shows up fine -- it appears as a new tab page on a tab control. The web browser is there and I can close everything without problems. (The web browser being placed normally at design time, not created dynamically yet.) However, if I use the navigate or navigate2 methods at any point and shut down the system then I get a run-time error 216 (which, IIRC, is an access violation at a point in a unit where the standard exception handler isn't available, in the initialization or finalization sections linky). This error happens at the very end of the program, rather than being an immediate thing.

    The problem happens both with standard design-time objects and with dynamically creating 'em. For dynamically creating them, I've used code something like this (don't have the project to hand since I'm at home):

    Code:
    Dim webby as WebBrowser ' VB Sucks
    
    Set Webby = Controls.Add&#40;"Shell.Explorer.2", "webby"&#41; ' VB REEEEALLY SUCKS
    
    'uh, can't remember the exact values for below
    Webby.Left = 0 ' it sucks
    Webby.Top = 0 ' yes it does
    Webby.Width = 3000 ' it really really does
    Webby.Height = 3000 ' etc
    
    ' inside a button's click event
    Webby.navigate&#40;"http&#58;//www.google.co.uk"&#41;
    
    ' killing it
    set Webby = Nothing
    (Declared in their respective sections/subprocedures, of course.)


    I'm using the web browser component in shdocvw.dll (project>components>Microsoft Internet Controls).

    I've been lead to believe that the main software was written in Delphi (some of those toolbar icons look very familiar :roll. It's possible that the original people dropped the ball twice -- but I'm annoyed here, because I can't see a reason for the web browser to give a 216 at the end but for other controls to work okay (which they seem to).

    Any advice would be much appreciated, Xorcist. Thanks!
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  6. #6

    Ugh - Visual Basic "fun"

    What exactly is this third party software you're using? And how does it interact with the VB application you're writing. It sounds like it might be an issue on their side of things (if using standard VB controls like buttons makes things go haywire). Which might be hard to fix if you don't have the source to fiddle around with. If there is any chance you could pass me their example program I'd be more than willing to take a look (though I know this might not be possible with licensing issues etc.).
    My DGDev forum pascal syntax highlight settings:
    <br />[background=#FFFFFF][comment=#8080FF][normal=#000080]
    <br />[number=#C00000][reserved=#000000][string=#00C000]

  7. #7

    Ugh - Visual Basic "fun"

    Sorry, but I won't be able to give you access to the thing -- it's a plug in to a separate system that's reasonably sensitive (used by GPs( and doesn't do much unless you've got it. I'll send the code for you (it's virtually nothing at the moment, and definitely nothing sensitive as far as I can see) as a private message. Cheers.

    I finally got in touch with the help desk of the external company. They say that a mail I sent a couple of days ago is now in the hands of the developers. I hope that's the case and that both of these problems are their fault .
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  8. #8

    Ugh - Visual Basic "fun"

    I switched over to Delphi from Visual Basic to see if it helped. As it turns out, one of the problems (crashing when having a focused control) went away with this change, but the 216 stuck around.

    I finally found the answer, though! It turns out that the help files may have been lying. I browsed around Usenet for a while and found some advice that said to use OleInitialize(nil) and OleUninitialize if I'm using the webbrowser. So... I did. But it still didn't work.

    In the meantime, I enjoyed the following sidetrack: http://tinyurl.com/djc6

    The webbrowser component apparently has a nasty memory leak. So I fixed that, but it still didn't work. I also bumped into this post, poor soul. That's exactly the problem I was experiencing. The unlucky person never got an answer.

    So anyway, I finally found this post. PRAISE THE LORD! The help files said to call OleUninitialize if OleInitialize gave back S_OK or S_FALSE "to close the library gracefully." I don't know about you, but I don't consider a 216 error graceful! So I only called OleUninitialize if I get S_OK for the first func. It works. I don't know whether it leaks memory but to be honest, I don't give a flying four letter word.

    And now my thing works.

    Here's some advice for anyone who'll be risking using a webbrowser in an OCX -- consider killing yourself instead. It'll give you less stress in the long run. I'd like to say thanks to Xorcist, who gave a few hints [which didn't pan out, unfortunately] while I was still fiddling away with the VB project. Also, thanks to the particular person who posted that solution in Usenet. Finally, a big swear word or three to anybody who designed ActiveX/Ole in the first place for making it such an over-engineered pain in the butt.
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  9. #9

    Ugh - Visual Basic "fun"

    LOL, my 2 worst nightmares in one post.... ActiveX is flakey and VB is just slow and awkward in places. I think the world would be a better place if Borland had developed an OS.
    http://www.c5software.co.uk (site is being developed at the moment)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •