I'm starting to code in, and learn, VB.NET. And so far, it's been smooth sailing.
Until I try to run the program.
What I've done is, in a language I know and understand, wrote a hangman game. And in C#, the code works perfectly. Once I got it to this finished point where I can say that there is nothing else I wish to change about it, I started hand-converting it to VB.NET.
So far, no problem. But I just finished converting it, and now I have hit my snag.
On the bottom of the window is a status bar, telling you which puzzle set you're in and which puzzle you're on. When selecting a puzzle, this line of code throws an error:
stsPuzzles.Text = "Puzzle: " + regionPuzzles + "/" + maxPuzzles
The error is:
Conversion from string "Puzzle" to type 'Double' is not valid.
Of course, the easy answer would be to take this mechanic out, but at least for testing purposes, I'd like it in there so I can make sure the right puzzles are in the right sets.
Is there a way I can fix this so my two integer variables can be in the string? Or is there a work around that I can at least use long enough for testing purposes for the rest of the testing process?
I'm hoping to find a way to fix this, as there are other places, such as displaying stats, that need to be able to do this.
The direct fix for your existing code is this:
stsPuzzles.Text = "Puzzle: " + CStr(regionPuzzles) + "/" + CStr(maxPuzzles)
or this:
stsPuzzles.Text = "Puzzle: " & regionPuzzles & "/" & maxPuzzles
In VB.Net, &, rather than +, is the concatenation operator. + will often still work, but it also has a tendency to think you wanted arithmetic when an operand is numeric.
But what I would really do in this case, is this:
stsPuzzles.Text = String.Format("Puzzle: {0}/{1}", regionPuzzles, maxPuzzles)
or with Visual Studio 2015 or later:
stsPuzzles.Text = $"Puzzle: {regionPuzzles}/{maxPuzzles}"
Related
Trying to develop an VS extension to help with migration from vb6 to Vb.net using Roslyn.
Unfortunately I am not having much luck with detecting the "DoEvents" expression in my source as I get NULL from my GetDeclaredSymbol during the detection.
My bad coding is......
Register the action:
context.RegisterSyntaxNodeAction(AddressOf ExpressionStatementDec, SyntaxKind.InvocationExpression)
Try and detect the "DoEvents" expression:
Private Sub ExpressionStatementDec(context As SyntaxNodeAnalysisContext)
Dim GotYou = context.SemanticModel.GetDeclaredSymbol(context.Node)
Dim WhatExpression = context.Node.ToFullString.ToString
' Find DoEvents.
If RemoveWhitespace(WhatExpression) = "DoEvents" Then
Dim diag = Diagnostic.Create(Rule, GotYou.Locations(0), GotYou.Name)
context.ReportDiagnostic(diag)
End If
End Sub
I have tried loads of options for trying to get the right type of object for "GotYou" but no luck so far.
Any pointers appreciated :)
Edit Additional info:
I have tried GetSymbolInfo but when I am detecting "DoEvents" in the context.Node.ToFullString.ToString I am still not getting anything in the context.SemanticModel.GetSymbolInfo(context.Node) as below.
Thanks,
Richard
If you want to look at what a invocation is referencing, call GetSymbolInfo not GetDeclaredSymbol.
Don’t have Visual Studio handy in order to get the code, but...
I believe what you want is something like:
Dim WhatExpression = TryCast(CType(context.Node, InvocationExpressionSyntax).Expression, IdentifierNameSyntax)?.Identifier.Text
This isn’t all of it, you could be dealing with a memberaccessexpression, in which case it’s probably not what you are looking for. The options would be a bit easier to handle with pattern matching in C#, but that’s the general idea. You don’t need the semantic tree at this point, because you first want to verify that you are dealing with the right text. Once you’ve got that, you can see where it comes from and whether it is something you need to deal with. Getting the semantic model is expensive, no reason to do so when (outside of your unit test) it is rarely going to be needed.
So I've been trying to do a calculator program in Visual Basic (shouldn't be too bad, I think). So far I got everything down and tested the operators individually. What I'm trying to do is to have the equals sign be able to determine which operator to use and go with it according to the button pressed for operator. I thought maybe if/else or switch/case could work, but I'm either getting addition first (it's the first in the choices) or nothing at all
Maybe I'm validating the wrong variable perhaps. I thought maybe that as an example:
if btnEquals.Text = "(insert operator sign here)" Then
{insert operator statement here}
on an if/else or case would do it, but it's simply not. I have checked in SO for any similar issue in VB, but most are for another language. I know I have to do something to ensure that the buttons coincide with the logical statements
Basically: How do I make the "=" button in the calculator program do the right arithmetic operation when the "+", "-", "/", "*" buttons are pressed? I tried if/else and case/switch and it's not logically giving the right answers.
Edited to clarify for other users.
Thanks in advance!
Already found an easy way to do it and it worked, it was simpler than I thought and was pulling my hair for no reason. Just for future reference. I just added a type char variable and with each arithmetic button (+,-,*,/) assign the arithmetic symbols to the variable and then use if/else or case switch in the "=" button to validate that variable.
Anyone with higher rank, you can go ahead and close this one. Thank you!
I have following sample code
Dim q As Char = "a"
Dim res As String = CStr(AscW(q))
res contains correctly "97" but when I use AscW(q) in watch or immediate it returns message: Cannot convert to 'Integer'.
Is it a bug or Visual Studio or am I doing something not correctly?
How can I see a character code in Immediate.
Note
The code presented is just an example. I found the problem when trying to see Character code in the Watch Window.
For a workaround, how about the command
? System.Text.Encoding.Unicode.GetBytes(q)
I personally believe that any acceptable VB.Net code should be acceptable in the Immediate window and really don't understand why AscW is causing errors when VB.Net offers no equivalent (e.g. in C#, but not VB.Net, you can cast a Char variable to an Integer to get the character code).
You are doing everything right (and the outputs will be OK in any case), although you are using old VB code. If you need functionalities like AscW (, Asc, ChrW, etc.), you would have to rely on this "old code" to get what you want (directly or via Microsoft.VisualBasic.Strings which, btw, does not show a different behaviour). But, in any other case, you should avoid the utilisation of this old code.
Test these two lines in the Immediate Window:
Dim res As String = CStr(5)
res = 5.ToString()
As you can see, you get an "error" (VS 2010, right-click on the line and select "QuickWatch") in the first line (old version), but not in the second one (.NET version).
Thus, the behaviour you observed can be considered as an inoffensive bug (no real effects in the execution) more or less understandable if you analyse the situation (you are asking a certain language (VB.NET) to support all its own features and the ones from an old language (VB); with the old one, some secondary functionalities might not be perfect).
I have an application which contains the line below to assign a parsed XML value to a variant array.
V(2) = latNode.Text * 1
This works fine on my system (Windows 7, Excel 2010) but doesn't work on some other system or systems - and I've not been able to get a response from the user who reported the problem.
I've switched out the offending line for:
V(2) = CDbl(latNode.Text)
This still works on my system, but then I had no problem in the first place. The question is on what systems does the first approach fail and why, and will the second method always work? I'm sure I've used the "String * 1" trick elsewhere before and would like to know how concerned I should be about tracking down other occurrences.
Thanks.
Maybe it's related to thousands separator and decimal mark. Office VBA uses cultural settings even in CDbl, in my German Excel version, it's reversed compared to English, CDbl("123.4") is parsed to 1234, CDbl("123,4") to 123.4.
Val(x) will always parse the dot as decimal mark.
I am working with Wolfram Mathematica 8 and have the following problem. I have an optimization problem under certain constraints and want to have an analytical (symbolical solution). I am maximizing function piA. My input is:
piA[a_, WA1_, WA0_] =
a/(1 + a)*(X - (y*WA1 + 1)^(1/y)) - 1/(1 + a) ((y*WA0 + 1)^(1/y));
Maximize[{piA[a, WA1, WA0], WA0 >= -1/y, WA1 >= -1/y}, WA0]
What I get most of the times is:
Maximize[{-((1 + WA0 y)^((1/y))/(1 + a)) + (
a (X - (1 + WA1 y)^(1/y)))/(1 + a), WA0 >= -(1/y), WA1 >= -(1/y)},a]
Basically, the command does nothing, but outputs itself. Only once I have managed to get the proper output (too long to paste here). I have tested it with simpler functions and it works. Unfortunately, I cannot understand what causes the problem. It is not a syntax problem, since it has worked like that several times. Any help would be very much appreciated.
P.S. Just checked again and my input ALWAYS generates the wrong output. The time it generated the solution was when I accidentally set parameters X and y to certain numbers.
The most likely reason is that given the function and constraints, Mathematica doesn't know how to maximize your function with respect to WA0. Note you also have a free variables X and a in there, and it might not have enough information about the domain of X and a to be able to properly form a solution to your equation.
I've had instances where I tried feeding in some equations and constraints and Mathematica simply couldn't do anything with them because they were too general. This may be the case here as well. Is there a specific problem you're trying to solve, and is there any way you could give Mathematica more context?
I don't think this is a bug at all, but it's unfortunate that sometimes Mathematica will just spit back your input when it doesn't have any rules for solving what you gave it.
The usual reason these things happens seems to be when the expressions given are too general for Mathematica to handle, or when it it's faced with a set of expressions that are ill formed.
Just as an example, I tried passing in fractions into a function I wrote that specifically looked for rational expressions, thinking it would work. It turned out that it needed to handle both Rational[a, b] and Times[a, Power[b, -1]]. It could be the case that Mathematica is not expecting a constraint to be of the form GreaterEqual[a, b].
Mathematica returns an answer if you assign the variable a some value. Maybe you could build your strategy on that? In fact it does provide an answer if you assign a value to any of the variables.
( I would need more background of the problem to go from there... )