 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / General 2 / March 2004Msgbox giving runtime error 13 - type mismatch
Hi All, I am about to finish my first proper VB program and today decided to make a compiled version to see if it ran any quicker. To my horror I got errors which never existed running in debug mode when running as a stand alone exe on the same pc. This is the line that produces the error: If MsgBox("Errors occurred during import, do you wish to see the log file?", vbYesNo) = vbYes Then I have also tried assigning it to a variable then testing the variable but get the same error, any ideas?? Cheers Craig > I am about to finish my first proper VB program and today decided to > make a compiled version to see if it ran any quicker. To my horror I [quoted text clipped - 8 lines] > I have also tried assigning it to a variable then testing the variable > but get the same error, any ideas?? I just ran that line and it works fine in either the IDE or when compiled. You didn't really give us enough information to help you though... tells us exactly what error message(s) you are getting (just saying "I got errors" tells us nothing). Rick - MVP >> I am about to finish my first proper VB program and today decided to >> make a compiled version to see if it ran any quicker. To my horror I [quoted text clipped - 16 lines] > >Rick - MVP Hmmmm... Seems to me the Subject Line gives you a little bit of a clue Rick... <g> Have a good day... Don ROTFLOL.... What, now I'm supposed to read the Subject lines too!??! Rick > >> I am about to finish my first proper VB program and today decided to > >> make a compiled version to see if it ran any quicker. To my horror I [quoted text clipped - 22 lines] > > Don > This is the line that produces the error: > If MsgBox("Errors occurred during import, do you wish > to see the log file?", vbYesNo) = vbYes Then Nothing wrong with that line. Works fine here, both in the IDE and as a compiled exe on both my Win98 and WinXP machines. Just a stab in the dark, but have you by any chance got a Timer running that might be up to no good when your message box gets displayed? The VB Timer stops running when you run your code in the IDE, but it continues to run when you run your code as a compiled exe. Mike > Hi All, > [quoted text clipped - 14 lines] > > Craig > > Hi All, > > [quoted text clipped - 10 lines] > > I have also tried assigning it to a variable then testing the variable > > but get the same error, any ideas?? There are hints buried in there: 1. Error doesn't occur in IDE, only in compiled program. How do you know it occurs on that line? 2. Type mismatch occurs during assignment statements, not comparisions. Must be a line before or after that. Is Option Explicit set in every module? 3. Error doesn't occur in IDE, only in compiled program. What could be different? MsgBox mentions a log file. Hmm. Maybe the current directory. Try putting ChDir App.Path at the beginning of your program. >Hi All, > >I am about to finish my first proper VB program and today decided to >make a compiled version to see if it ran any quicker. To my horror I >got errors which never existed running in debug mode when running as a >stand alone exe on the same pc. Always run an App in the IDE using [Ctl F5] - never just use [F5] Always put: Option Explicit : DefObj A-Z at the top of each code module Steve's tip: ChDir App.Path is also wise > Always run an App in the IDE using [Ctl F5] > - never just use [F5] [quoted text clipped - 3 lines] > > Steve's tip: ChDir App.Path is also wise I saw the DefObj A-Z suggestion on this newsgroup some time ago, and it looked like a great idea. So I put it into each of the 100 or so modules in my program -- and then found a trap. For example, let's say you write a function and forget to explicitly give it a type: Public Function Stuff() Stuff = "stuff" End Function And call it someplace in your program: MsgBox Stuff Sure enough, if you call it in the IDE, you'll get an error message. But the sucker will compile just fine. So if, in your testing, you failed to call that particular function, the trap is set, and the poor user who does cause that function to be called in the compiled program will be rewarded with a program crash. If you do use the DefObj A-Z idea, I suggest using a compiler switch: #If InIDE Then DefObj A-Z #End If And then *don't forget* to turn off the compiler switch before compiling the version you're going to send out into the real world. Roy Lewallen >> Always run an App in the IDE using [Ctl F5] >> - never just use [F5] [quoted text clipped - 31 lines] >And then *don't forget* to turn off the compiler switch before compiling >the version you're going to send out into the real world. I agree that it is a real pain that the error will not show up in the compiling, - but I'm not that keen on sending out code that works differently from the stuff I've developed When I started using DefObj A-Z, I went through every Function and Property manually checking the code I think that if this really became a problem for me, then I would write a simple program to identify all Functions and Properties I can't repro that (VB6). Following your steps I get error 91 in the IDE until the Stuff() function is explicitly typed (even As Variant). I suggest you retry this, but do a start with full compile to run in the IDE.  SignatureRandy Birch MVP Visual Basic http://vbnet.mvps.org/ Please respond only to the newsgroups so all can benefit. : > Always run an App in the IDE using [Ctl F5] : > - never just use [F5] [quoted text clipped - 33 lines] : : Roy Lewallen > I can't repro that (VB6). Following your steps I get error 91 in the IDE > until the Stuff() function is explicitly typed (even As Variant). I suggest > you retry this, but do a start with full compile to run in the IDE. Yes, you get an error when calling the function either in the IDE or in the compiled program. The danger is that if you didn't call the function during testing, the problem is still in there. It compiles just fine. Although the programming was careless, there was no error and no problem *until* the DefObj A-Z statement was added. Adding the statement *created* an error that didn't previously exist -- and one that remains hidden unless that particular function was tested either in the IDE or compiled program. That was my point. It would probably be fairly safe if you put the DefObj A-Z statement in each module as you first write the program, because chances are you'll be exercising each of the functions you create. Or, if the program isn't too complex, you can check each one as J did. What I did was put the statements into a working program with about 100 modules and probably 2000 or so functions and subs, so it wasn't practical to try and manually test each one. So what the DefObj A-Z did for me was to set a dangerous trap just waiting to spring on a user. I was fortunate to discover the trap before I released any copies to my customers. Writing a program to find untyped variables, parameters, and functions is in my opinion a much safer way to go. Roy Lewallen ah .. "didn't call during testing". I can repro that. SignatureRandy Birch MVP Visual Basic http://vbnet.mvps.org/ Please respond only to the newsgroups so all can benefit. : > I can't repro that (VB6). Following your steps I get error 91 in the IDE : > until the Stuff() function is explicitly typed (even As Variant). I suggest : > you retry this, but do a start with full compile to run in the IDE. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.