I have the following line of code in ASP.Net (VB)
Response.Write("<td class=""tblRow""><strong>" & ITServiceRow.NAME & " </strong><br>" & funcRAGColour(ITServiceRow.RAGSTATUS) & Environment.NewLine)
This should output the Name from ITServiceRow.NAME followed by the result of the function funcRAGColour.
However this is not the case. ASP.Net is outputting the value of the function funcRAGColour. first followed by the value of ITServiceRow.NAME.
Just trying to understand why this might be happening? If I replace the function with static text it executes fine, but when I put the function in it outputs the function result immediately before the name.
The image here, in yellow shows the full output that comes from the function, it is shown before everything else?
Am I missing something obvious here?
Try using String.Format instead to guarantee placement.
Response.Write(string.Format("<td class=""tblRow""><strong>{0}</strong><br />{1}{2}</td>",funcRAGColour(ITServiceRow.RAGSTATUS),Environment.NewLine))
Always do whatever you can to avoid string concatenation. String concatenation is tough on a system and uses much more memory and resources to be garbage collected than you think because it's actually far more complicated. String.Format and StringBuilder help get around this.
I am very suspect of the function funcRAGColour() itself though and think that is the problem. My guess is the function is not returning the output as a string, but instead is using Response.Write() to output it's result. That would cause it's value to appear first since it is called while the string is being assembled.
Keep in mind, Response.Write is NOT the way to do things in ASP.Net. It was need in classic ASP, but ASP.Net has HtmlTextWriters that can be used during the rendering process, controls for result placement, etc.. It's the old school, non object-oriented way of doing things that can get into trouble.
Related
Can anyone tell me what each of these are doing?
<%call buildBanner()%>
What I think this one is doing is calling a Method But I'm not that familiar with ASP.
Dim nInstallID : nInstallID = getParam("InstallID")
This I'm not quite sure, But from What I gathered it's a string. But I'm not sure what the ":" does or is doing.
The "call buildBanner()" is calling a function from somewhere else in your code. The function could be on the same page or it could be in an "include" file.
The ":" is just a way to separate commands on the same line. Normally you would put the two parts on two separate lines, but this is a shortcut way to use one line. Some people like to declare and initialize the variable on the same line - something you can't do in a single statement in Classic ASP.
This is the strangest thing and I can not figure out how this is happening. Some how a user on my asp.net website is creating a multiline string but is not using the normal carriage return or linefeed.
I have tried to figure out how this is being accomplished.
It is a multiline textbox and when you press enter it goes to a new line.
In the aspx code I am using the following code to break the string into an array and count the lines in the array.
Dim text as String = txtMessage.Text.Trim
Dim Array as String() = text.split(vbNewLine)
Return Array.Length
I most normal situations when there is a line wrap it goes to the next line a CR/LF is entered and the code will break the string into a new line. Also pressing enter creates a new line and the split function works separating the lines and creates the dimensional array based on number of lines.
There is just one user that is some how creating a new line using a nonstandard CRLf. It is causing the split by vbnewline to not catch and break the string into an array. I have never seen this happen before.
I'm not asking how to fix this. I think I have a good idea how to keep this from happening by doing additional checks on the string through regex.
I am just completely puzzled as to how this is happening. If you have seen this before or have an idea of how this is accomplished then I would love to hear your thoughts.
Here are things I have tried: Inserting HTML into the string( didn't work )
: manually adding line breaks in the string such as \r, and using Hex codes to confuse the split function (didn't work)
:Injecting Script into the string(didn't work)
:Used access and excel to create strings without using a standard CRLF and copy and pasting (didn't work).
I have 5 yrs coding experience and am completely intrigued. Can you solve this?
What OS are you on? VbNewline is platform-dependent -- if your server is on Windows, that means \r\n. Since you're producing a web application, it's possible that not all of your users are on Windows -- and different OSes record line breaks differently -- they could well be VbCrLf (\r\n), VbLf (\n), or VbCr (\r), depending on whether your user is on Windows, Linux, or Mac respectively. You'll have to detect which one the user is transmitting and split your array on the appropriate combination of characters.
This answer from Karl Nicoll has more useful information for a user who experienced a very similar problem.
I'm doing some client-side stuff with Javascript/JQuery with .Net controls which expose their GUID/UniqueIdentifier IDs on the front end to allow them to be manipulated. During debugging something is driving me crazy: The GUIDs in the db are stored in uppercase, however by the time they make it to the front end they're in lowercase.
This means I can't quickly copy and paste IDs into the browser's console to execute JS on the fly when devving/debugging. I have found a just-about-workable way of doing this but I was wondering if anyone knew why this behaviour is the case and whether there is any way of forcing GUIDs to stay uppercase.
According to MSDN docs the Guid.ToString() method will produce lowercase string.
As to why it does that - apparently RFC 4122 states it should be this way.
The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.
Also check this question on SO - net-guid-uppercase-string-format.
So the best thing you can do is to call ToUpper() on your GUID strings, and add extension method as showed in the other answer.
If you're using an Eval template, then I'd see if you can do this via an Extension method.
something like
public static string ToUpperString(this Guid guid, string format = "")
{
string output = guid.ToString(format);
return output.ToUpper();
}
And then in your Eval block,
myGuid.ToUpperString("B")
Or however you need it to look.
I'm on my Mac at the moment so I can't test that, but it should work if you've got the right .Net version.
I currently have this line of code which has been working for the past 6 months:
If IsNumeric(txtProductID.Text) Then
...do stuff
Else
Dim msg As String = "Error!"
End If
All of the sudden, no matter what kind of entry is put in txtProductID (including plain numbers), it fails! Is there reason for me to be going crazy over this?
Kind of a shot in the dark, but one thing to watch for is that maybe someone wrote a private method called IsNumeric within the same class. Are you sure that the code above is executing Microsoft.VisualBasic.IsNumeric()? If you put your cursor on IsNumeric and hit F12 where does the definition point to?
Try Trim()ing the string before passing it into the function. In addition, rather than using a VB-specific function like IsNumeric, you might try an approach like this:
Dim input as Integer
If Integer.TryParse(txtProductID.Text, input) Then
....do stuff with input
Else
Dim msg as String = "Error!"
End if
If your number is a decimal number, there are corresponding functions on Double and Single as well.
As to the particular reason that IsNumeric is failing, I couldn't tell you. I can tell you, though, that I've always found it helpful to stick to BCL-compliant functions that are language-agnostic rather than language-specific, like IsNumeric, Str, etc.
ugh... i'm an idiot... thanks for your help guys, but apparently i was clearing my whole form before accepting input, so "" will never pass as "IsNumeric". Please don't look at this question again. I feel ill.
Thanks again for your help.
I have a query string parameter value that contains an ampersand. For example, a valid value for the parameter may be:
a & b
When I generate the URL that contains the parameter, I'm using System.Web.HTTPUtility.UrlEncode() to make each element URL-friendly. It's (correctly) giving me a URL like:
http://example.com/foo?bar=a+%26b
The problem is that ASP.NET's Request object is interpreting the (encoded) ampersand as a Query String parameter delimiter, and is thus splitting my value into 2 parts (the first has "bar" as the parameter name; the second has a null name).
It appears that ASP.NET is URL-decoding the URL first and then using that when parsing the query string.
What's the best way to work around this?
UPDATE: The problem hinges on URLRewriter (a third-party plugin) and not ASP.NET itself. I've changed the title to reflect this, but I'll leave the rest of the question text as-is until I find out more about the problem.
man,
i am with you in the same boat, i have spent like hours and hours trying to figure out what is the problem, and as you said it is a bug in both, as normal links that contain weird characters or UTF-8 code characters are parsed fine by asp.net.
i think we have to switch to MVC.routing
Update: man you wont believe it, i have found the problem it is so strange, it is with IIS,
try to launch your page from visual studio Dev server and Unicode characters will be parsed just fine, but if you launch the page from IIS 7 it will give you the ???? characters.
hope some body will shade some light here
I would have thought that %26 and '&' mean exactly the same thing to the web server, so its the expected behavior. Urlencode is for encoding URLs, not encoding query strings.
... hang on ...
Try searching for abc&def in google, you'll get:
http://www.google.com.au/search?q=abc%26def
So your query string is correct, %26 is a literal ampersand. Hmm you're right, sounds like a bug. How do you go with an & instead of the %26 ?
Interesting reading:
http://www.stylusstudio.com/xsllist/200104/post11060.html
Switching to UrlRewritingNet.UrlRewrite did not help, as it apparently has the same bug. I'm thinking it might have something to do with ASP.NET after all.
I think URLRewriter has a problem with nameless parameters (null name).
I had a similar problem. When I gave my nameless parameter a (dummy) name, everything worked as expected.