Here's an interesting thing, I have used Visual Studio 2010 previously to make basic VB programs, and never had an issue with anything. Now I am just perplexed as to why this is happening.
I haven't even gotten very far into the coding phase of the first form, and already I am getting yelled at for a syntax error when I use "Me", whether it is Me.Close(), or whatever. Instead of posting the code as text here, it would be best to just show the syntax highlighting.
http://kelina-enterprises.com/img/vb-syntax-error-stackoverflow.png
::EDIT:: This image was taken down, it is not a real error.
Here's the funny thing, when I test the program, it runs just fine if I run the last successful build, which executes those "errored" lines.
Is this something I should even concern myself with, or should I just ignore these apparently false syntax errors?
Do keep in mind that if this is something simple that I have just neglected to take care of for some reason (nothing comes to mind), it has been about 3 years since I last used VB, and not even for a year at that.
You cannot write VB statements inside a Class, such as, Me.Close() or MessageBox.Show("??"). For example,
Class Test
MessageBox.Show("test")
End Class
is obviously syntax error
Inside a Class, you can write only declarations or methods.
In your case, you can place the codes in the Load event handler like this ...
Private Sub LoginForm_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
'Fullscreen, over everything, maximized
Me.Width = My.Computer.Screen.WorkingArea.Width
Me.Height = Screen.PrimaryScreen.Bounds.Height
Me.CenterToScreen()
Me.TopMost = True
Me.WindowState = FormWindowState.Maximized
End Sub
You don't need to type-in the Private Sub ... End Sub. Go to form design, double click the form and the Load event should be appeared.
It looks like you mean to put that code within the load event of the form, you can't have code that's not inside some sort of routine.
If you double-click on the form in design mode, the load event should be automatically created for you and you can then move the code into it.
There are also other events of the form that you may want to use, e.g. Shown event, these can be created by clicking on the appropriate selection in the drop-down box next to the one that has LoginForm selected.
Related
So.. I just downloaded Xojo 2014 for OS X, and up to this point have found it a pretty simple and effective development environment.
However, I've been trying to make a function or sub routine for 45 minutes. Every time I try following tutorials or the Xojo documentation I get the following error:
I've followed (even though I could be missing something) the directions here: http://docs.xojo.com/index.php/Function
Even though there is no full example in the documentation (bad development environment).
Also, in the screen shot is showing a sample function I copied and pasted off Xojo forums and is supposed to work. I'm not a programming newb per say, but more an Xojo newb. I've also had experiences with silly bugs in RealStudio in the past.
Can someone maybe point out what I could be missing?
You cannot use the Function, Sub, End Function, or End Sub lines in the method editor. Doing so will cause a syntax error because method declarations are automatically added by the IDE based on the values you enter into the method editor's name, parameters, and return type fields.
e.g.
as said,
Function, Sub, End Function, or End Sub is done for you,
you can do 'exit sub' if nothing need to be returned, else just return a proper value
like some events need a true or false, so if you need the exit the function, just return false
You cannot add inline functions within your Xojo code. You add methods to your project items these ways:
Insert->Method
"+" button on editor toolbar, then Method
Insert button on main toolbar, then Method
Option-Command-M (on OS X)
This seems like an awfully basic question, but I still can't find an answer for it.
In VBScript, is there any harm in declaring the same scalar variable with the Dim statement more than once?
I'm working on some related projects and developing some code pieces I'd like to reuse. However, I'm slightly concerned if there's a problem with using code that uses the same variable name twice, like so:
Dim i
for i = 1 to Count
'* doin' somethin' here
next
Dim i
for i = 1 to UnrelatedOtherCount
'* doin' somethin' different yo
next
It's not just iteration loop variables, either; I may have multiple places in a script where regexes are used. If my script uses two sections of code being re-used, and each of them uses a "patternString" variable and starts by declaring the variables:
'* first section of code from the folder
Dim objPersonRegex, patternString
Set objPersonRegex = new RegExp
...
'* a completely different section of code
Dim objBuildingRegex, patternString
Set objBuildingRegex = new RegExp
My instinct is to say that it shouldn't be a problem, that Dim just creates a variable of the given name if it doesn't already exist, and if it does, just goes on because what it was told to do is done. But is this actually the case? In case it matters, these are scripts running on Windows Script Host.
(To clarify what I'm worried about, I'm not worried at all about the value of the variable getting clobbered. If I need to retain the value of the variable, I'll save it in a different variable, one with a unique name.)
All my attempts to look up the answer myself have failed; they only return information about declaring more than one variable on a line, and using ReDim on arrays.
Is it harmful to Dim a variable more than once?
It is impossible to Dim a variable more than once. Neither not using Option Explicit nor (mis)using On Error Resume Next will get more than one Dim for the same variable (name) in the same compilation unit past the 'compiler'.
Dim doesn't just create then re-create the variable. It allocates a memory address for it.
So, assuming you are coding with OPTION EXPLICIT turned on, it won't let you even do that.
However... What you're showing there as an example is not declaring the variable again. Not the same way, at any rate. That's not "dimmed". It's just temporarily used and thrown away when it's done. So, in that respect, you are doing it the right way.
If you were to create a new variable for every little thing that ran in a loop, when they don't interefere with each other, that becomes rather inefficient.
In the first example, I would say that it is harmful, because it means you're coding with OPTION EXPLICIT OFF. Don't do that. Keep that option on.
For the second example, if they really are different sections of code, in different "namespaces" (as much as vbscript has that concept... different modules, I guess), you're probably okay. However, that code is similar enough that I would look into writing a method that does whatever it is you're about to do. Then just call the method.
However, if snippets in the second example are in the same module, it would be a problem... partly for the reason in my first paragraph, and partly because it can lead to a very specific kind of bug. Imagine you make a mistake in your code, where it's possible somehow in the last sample for patternString to go unassigned. If it's a completely new variable, that results in an error, such that we know something went wrong. With the current code, it's possible to run the code with old pattern. This is worse than an error, because it may cause the program to do things like make unexpected changes to a database, or show sensitive data to the wrong user.
I don't know that the following piece of code is really relevant, but for the sake of full disclosure here is the code I was trying to call from the Immediate Window:
abstract class Test
{
public int x;
public Test()
{
x = 5;
}
}
class TestImp : Test
{
public int GetX()
{
return this.x;
}
}
It was just a test to see whether the default base constructor gets called automatically or if I have to call it specifically because I couldn't remember.
Okay, on to the problem. I typed this into the Immediate Window to see the result:
new Mercury_Reports.TestImp().GetX();
And rather than evaluating the expression it just started my application. I closed the app and tried again two more times and got the same result. The next time, I went and put a breakpoint in my Program.cs file. Then instead of starting the app like it did the last three times and then hitting the breakpoint, it decided to actually just evaluate my expression.
I've seen some weird things in the Visual Studio IDE before, but I think this is one of the weirdest. Anyone have a clue as to what was going on there? :)
When evaluating an expression in the immediate window when you're not debugging the following process takes place
Loads your project / application binaries into the hosting process
Silently attaches the debugger to the hosting process
Evaluating the expression against that debugger session
Most of the time this is done in a way that makes it hard to detect that the application is actually being run. But occasionally a side effect of the application shows through and reveals what's really going on under the hood.
EDIT
In general it shouldn't be displaying the UI though. I can think of some obscure corner cases where this would happen though and not be a Visual Studio bug. The basically all come down to the same scenario though
The evaluated string causes an unintended side effect to happen at a time where it wouldn't happen during normal program flow.
This is actually more common than you'd expect in the immediate window because it's essentially executing your code out of order. Normally you'd never get to new Mercury_Reports before executing Program.Main but in the immediate window this is exactly what happens. This can have nasty effects like re-ordering static type constructors
Here are some unintended consequences which can surface via an immediate window expression
Cause types to be loaded and hence cause their static initializers to run
Change the order in which static initializers are run
The return type of the expression has a ToString method the debugger executes
The return type of the expression has a DebuggerDisplay value which the debugger executes
In the past I have seen the static constructor case cause UI to show. Essentially a static type constructor was evaluating MainForm.Instance (a lazy creation property). During normal program flow it was called from Program.Main was run and from then on was simply available. In the immediate window though Program.Main didn't run. But the expression being executed inadventently loaded that type and hence displayed the UI for what was a trivial property getter.
This is a pretty obscure corner case though. I'd say the most likely cause here is a bug in Visual Studio. Debugging is nasty business, especially when executing live code, and this is probably a symptom of that.
I have a vb6 app that uses Word interop to create a few reports. In the introduction of these reports, there are some instructions in 4 textboxes around an image.
Recently and suddenly the top two textboxes started appearing on the next page, and I can't figure out why. When I step through the code and watch the word document getting built, everything positions itself correctly, however, if I compile the application, the error reappears.
Any suggestions?
Use late-bound calls to Word. This does not mean to remove reference to Microsoft Word Xxx Object Library, just alter your Dims like this
Dim oWord As Object '--- was Word.Application'
Dim oDoc As Object '--- was Word.Document'
...
oDoc.Protect wdAllowOnlyReading '--- keep using enums'
Could it be some 'rounding' difference? For instance if you compare two float point values for equality, the result can subtly depend on the specific compiler/interpreter implementation.
I would like to suggest to trim down your code to the minimum showing the different behaviors. That might clear things up already. If not, please post it here to let us help you.
Maybe you are running the compiled version as a different user than the one running VB when you debug? Maybe this could cause what you are describing, if the two users have some different Word settings.
Is it possible that the compiled version finds a different version of the .dot file?
It may be very helpful if you show the code you use to create the Word document, because then someone here might notice something that can be sensible to moving to a compiled version.
Do you have any code in events that rely on timing, such as Form_Activate, Load, or Unload? I've seen those things behave very differently when stepping through code and when compiled, especially on newer, faster machines.
Very simple question that is apparently impossible to find a decent answer to: How can I make Visual Basic 6 stop changing my ^##*ing variable casing!?!
I know that the general opinion of a great many VB users is that this "feature" is actually quite helpful, but I doubt that they use it much with any source control system. This is absolutely INFURIATING when you are trying to collaborate on a project of any significant size with several other developers. If ignored, you produce thousands of false-positive "changes" to your files (even ones with no actual code changes!) that pollute the revision history and make it near impossible in some cases to locate the actual change that took place.
If you don't ignore it (like my office, where we have been forced to implement a "no unneeded case change" policy), you spend 5x the time you would normally on each commit because you have to carefully revert out VB's "corrections" on every file, sometimes reverting hundreds of lines to put in a one line change.
Surely there must be a setting, plugin, hack, etc. out there that can remove this unwanted "feature"? I am willing to take any method I can get as long as it doesn't require me to pick through piles of phantom diffs. And to squash a couple of complaints up front: No, I can't turn off case detection in my diff tool, that's not the point. No, we can't just make the case changes globally. We're working with hundreds of thousands of LOC being worked on by multiple developers spanning many years of development. Synchronizing that is not feasible from a business standpoint. And, finally: No, we cannot upgrade to VB.net or port to another language (as much as I would love to).
(And yes, I am just a tiny bit peeved at the moment. Can you tell? My apologies, but this is costing me time and my company money, and I don't find that acceptable.)
Depending on your situation adding
#If False Then
Dim CorrectCase
#End If
might help.
Here is a real world scenario and how we solved it for our 350k LOC VB6 project.
We are using Janus Grid and at some point all the code lines which referenced DefaultValue property of JSColumn turned to defaultValue. This was an opportunity to debug the whole IDE nuisance.
What I found was that a reference to MSXML has just been added and now the IDE picks up ISchemaAttributes' defaultValue property before the Janus Grid typelib.
After some experiments I found out that the IDE collects "registered" identifiers in the following order:
Referenced Libraries/Projects from Project->References in the order they are listed
Controls from Project->Components (in unknown order)
Source Code
So the simple fix we did was to create a dummy class/interface with methods that hold our proper casing. Since we already had a project-wide typelib we referenced from every project before anything other typelib, this was painless to do.
Here is part of the IDL for our IUcsVbIntellisenseFix interface:
[
odl,
uuid(<<guid_here>>),
version(1.0),
dual,
nonextensible,
oleautomation
]
interface IUcsVbIntellisenseFix : IDispatch {
[id(1)] HRESULT DefaultValue();
[id(2)] HRESULT Selector();
[id(3)] HRESULT Standalone();
...
}
We added a lot of methods to IUcsVbIntellisenseFix, some of them named after enum items we used to misspell and whatever we wanted to fix. The same can be done with a simple VB class in a common library (ActiveX DLL) that's referenced from every project.
This way our source code at some point converged to proper casing because upon check-out the IDE actually fixed the casing as per IUcsVbIntellisenseFix casing. Now we can't misspell enums, methods or properties even if we try to.
SIMPLE WAY: Dim each variable in the case that you want. Otherwise, VBA will change it in a way that is not understandable.
Dim x, X1, X2, y, Yy as variant
in a subroutine will change ALL cases to those in the Dim statement
I can sympathise. Luckily we're allowed to turn off case sensitivity in our version control diff tool!
It seems the VB6 IDE automatic case-correction occasionally changes case in variable declarations and references, perhaps depending on the order in which modules are listed in the VBP file? But the IDE doesn't tell you that the file needs to be saved. So the problem only shows up when you saved the file because of another edit. We briefly tried to prevent this by checking out all the files in a project and setting the case carefully, but it didn't go away.
I suppose you could list the variable names that are affected - the usual suspects are one letter names like "I", "X" and "Y", perhaps because they are used in standard event handlers like MouseDown. Then write an add-in that'll search for all declarations " As" and force the case to upper. Run the add-in on your modules before you check them in. You might be able to trigger the add-in to run automatically when you save in VB6.
EDIT: Something I've just thought of: adapt Fred's answer. From now on, every time you check in a file, add a block at the top to establish canonical case for the usual suspects. If nothing else, it's easier than reverting hundreds of lines by hand. Eventually you will have this block in every file & maybe then the problem will stop happening.
#If False Then
Dim I, X, Y ' etc '
#End If
I standardised the case across the codebase, normally by using the examples above (Dim CorrectCase), and removing it again.
I then triggered VB to save EVERY file, by doing a case sensitive search/replace of "End" with "End" (no functional change, but enough to get VB to resave).
Once that was done, I could then do a single commit to standardise the case, making it MUCH easier to keep on top of it at a later date.
In this example VB6 was changing the case of the following line following a typo I made when referencing a library: -
Dim MyRecordset As ADODB.REcordset
Ugly, and now every other instance of an ADODB.REcordset thus acquired the new misspelling. I fixed this as follows: -
Type in a new declaration as follows
Dim VB6CasingSucks AS ADODB, Recordset
Note the comma and space after ADODB. Hit [ENTER] for VB6 to check the line.
At this point all instances of REcordset change back to Recordset.
Delete your new declaration.
I don't know if this fix will help with enums/other variable names.
Specifically for controlling the case of enum values, there is a VB6 IDE add-in which may be helpful. Enums seem to have a slightly unique version of this problem.
As described in the link below:
The VB6 IDE has an annoying quirk when it comes to the case of Enum
members. Unlike with other identifiers, the IDE doesn't enforce the
case of an Enum member as it was declared in the Enum block. That
occasionally causes an Enum member that was manually written to lose
its original case, unless a coder typed it carefully enough.
...
However, if a project contains a lot of Enums and/or a particular Enum
has a lot of members, redeclaring the members in each of them can get
quite tedious fast. ...
Ref: http://www.vbforums.com/showthread.php?778109-VB6-modLockEnumCase-bas-Enforce-Case-of-Enums
...load and unload the add-in as needed via the Add-In Manager
dialog box. Usage is as simple as selecting the entire Enum block,
right-clicking and then choosing the "Lock Enum Case" context menu
item.
I have a similar problem:
in a bas module there I wrote :
Private sub bla_bla()
Dim K as integer
End Sub
so in a class module the Dim k as integer will automatically be replaced by IDE become 'Dim K as integer' <-- it's not logical but then:
I correct the bas module become:
Private sub bla_bla()
Dim k as integer
End Sub
then magically the problem in the class module was solved (still be k and not automatically replaced by IDE become K). Sorry I'm poor in English
I don't think there's any to do it. The IDE will change the case of the variable name to whatever it is when it's declared. But, honestly, back in the day I worked on several large VB6 projects and never found this to be a problem. Why are people on your development team constantly changing variable declarations? It seems like you have not established a clear variable naming policy that you enforce. I know your upset, so no offense, but it might be your policies that are lacking in this regard.
Unfortunately, according to this SO thread, alternate VB6 IDEs are hard to come by. So, your best bet is to solve this problem via policy. Or move to VB.NET. :)
Wow. I've spent a lot of time programming in VB6 and I have no idea what you're on about. The only thing I can think you're referring to is that intellisense will change the capitalization of variable names to match their declarations. If you're complaining about that, I would have to wonder why the hell they've been entered any other way to begin with. And if that is your problem, no, there's no way to disable it that I'm aware of. I'd suggest you, in one go, check out every file, make sure the caps on the declarations and uses of variables all match and check back in.