|
I'm not sure the problem is to do with the string concatenation. In my experience, the VB.NET compiler will automatically invoke the ToString() method whenever a non-string variable is included in a string concatenation.
It is far more likely that it is how you are including the DateTime variable in the query parameter of the Compute() method. In both Microsoft Access and Microsoft SQL Server, including a date in a query string requires wrapping the date in # characters, not ' characters.
Try changing your query to:
Dim GnQy As Object = MyDs.Tables(0).Compute("sum(grn_qty)", "itm_code='" & ThsImCd & "' and grn_date<=#" & Dt2 & "#")
I have also bolded my changes.
|
|
|
|
|
Hi,
I have two comments:
1.
when dealing with dates and times, you should use the relevant classes, and avoid string operations as much as possible. So if the initial date information is in string format, turn it into a DateTime as soon as possible (using TryParse), then take advantage of all the methods and properties DateTime offers.
2.
Paramu1973 wrote: Dim Dt2 As DateTime = MaskedTextBox1.Text
You should not base your code on those implicit conversions, as they tend to hide potential problems that will bite you sooner or later at run-time. I suggest you start each file with "Option Strict On" (that may generate a couple of surprise messages, each of them needing a fix), then explicitly code the conversions you need (e.g. using DateTime.TryParse). For TextBoxes and other input Controls, be aware they may be empty (hence fail conversion), or contain unacceptable input (even a pretty good MaskedTextBox may accept a "February 31" which will cause havoc later.
|
|
|
|
|
Various forms in my app generate a list of names then place them into comboboxes in the format "Smith, John".
I noticed today that whilst most of these work fine, on one page, the comma gets turned into a dot i.e. "Smith.John"
I have compared all the properties of the comboboxes and they are identical (apart from the obvious differences in name, size, location etc.)
The method of generating the strings and loading them in are identical. If I change the comma to another character, it works just fine, anything but a comma!
Could there be a property of the Form that is causing this?
Cheers,
Rich
|
|
|
|
|
Sound like a localization issue.
See if your forms have the property Localizable set to False (and if there is a difference between the working and not working forms on that property)
Without having a look at the code that generates your list of names that's my best guess.
|
|
|
|
|
Tom,
Thanks, here's all the relevant code. Both forms had Localizable set to false and all other properties were the same (except the obviously different ones)
This is the code where the commas get replaced by dots ...
names = GetNames(dr)
RemindersCombo.Items.Add(names)
Private Function GetNames(ByVal MemDrow As DataRow) As String
GetNames = ""
If Not Convert.IsDBNull(MemDrow!Lastname) Then GetNames = MemDrow!Lastname & ", "
If Not Convert.IsDBNull(MemDrow!Firstname) Then GetNames += MemDrow!Firstname
Return GetNames
End Function
And in this one (where I already know there are no nulls and do not need to check) it works just fine ...
If flag = True Then
name = dr!lastname & ", " & dr!firstname
OverdueCombo.Items.Add(name)
ListOfOverdue.Add(dr!Mnumber)
End If
Cheers,
Rich
|
|
|
|
|
did you check your database content?
e.g. you would get A.B if lastname were empty and firstname were to contain A.B
|
|
|
|
|
Good thinking but no, they are mostly sensible names!
Rich
|
|
|
|
|
maybe OT, why are you passing the DataRow by value?
|
|
|
|
|
Well, it's some yesrs since that was written so I'm guessing but I probably never typed the ByVal, my lazy practice being to simply type [VarName} as [type] and let the IDE do the rest unless I specifically want a ByRef.
Rich
|
|
|
|
|
I suggest you switch to ByRef here, I see no need to have the data copied.
|
|
|
|
|
In this simple situation I agree. However, in general, I am slightly wary of a variable in one place getting potentially changed somewhere else, preferring to call helper methods that return data that I can then choose to apply or not, depending on the situation.
I fully accept that this may not be everyone's best practice but to me, it makes it easier to keep track on what's going on, at the expense of a few bytes!
Regards,
Rich
|
|
|
|
|
So I copied the "working Combobox" into the other form, renamed it and ran the app, it worked perfectly, the comma displayed as it should.
I then shrunk the box a tad and reduced the point size from 11 to 9.75 (to match the others on the form)and lo and behold - the "error" recurred with the comma being replaced by a dot!
Upon further investigation, with a point size of 10.126, the comma displays. With a point size of 10.125, you get a dot.
WTF????
Rich
|
|
|
|
|
Here are a few possibilities:
1. your Font is defective; while trying to display a comma, it actually contains a period for that particular size. Try a different font family.
2. maybe you need to go and see an ophthalmologist.
|
|
|
|
|
Spectacles are just a couple of months old, so I thought I'd try a few more ideas.
Knocked up a form with two columns of 10 comboboxes. Left 10 at 10pt, right 10 at 11pt, each pair with a different typeface.
Microsoft Sans Serif and Haettenschweiler both turned commas to dots at 10pt on an XP machine
Ran the prog on a new Win 7 laptop, exactly the same result. The same thing does NOT happen in a Word doc.
Not sure I have the time or the patience to repeat for lots more fonts, but this is interesting (to me at least)
Rich
modified on Wednesday, June 16, 2010 5:22 AM
|
|
|
|
|
I did a little test myself, all looked normal.
I used Windows Vista, .NET 2.0, WinForms, fonts Courier New and Arial, sizes 10 to 13.
Can you:
- provide pictures
- confirm it is a WinApp (not a web site)
- explain what is a "page" (OP)
- specify your system
- clarify where it goes wrong: drop down list, textbox part of comobobox
- confirm characters with descenders look alright
- see it go wrong with constant data, i.e. no database code at all
|
|
|
|
|
I suspect the problem might be related to .net 3.5 - which is (I think) on both machines. I never noticed the problem before when still on .net 2, which I see you are using. Maybe try it with Microsoft Sans Serif and see what happens.
Yes, it's a Win App as is the test app I did this morning and tried on the two machines.
Goes wromg in both sections of the combo box.
Other descenders look fine, there seems to be room to display the commas, they just turn to what look like dots.
The test app used constant data and simply put a series of test strings into each combobox.
Zooming in on a screenshot, I notice that when comparing the pixels on what is visible of the top of the 10pt comma looks quite different to the top of the 11pt comma which displays properly although I guess this could just be down to the size difference.
Regards,
Rich
|
|
|
|
|
So I switched to .NET 3.5, added 8 and 9 point and Microsoft Sans Serif.
Then replaced comboboxes by simple text painting, so I could see all at once.
This is my code:
public void Run() {
Form form=new Form();
form.Bounds=new Rectangle(100, 100, 600, 600);
form.BackColor=Color.White;
form.Paint+=new PaintEventHandler(form_Paint);
form.Show();
}
void form_Paint(object sender, PaintEventArgs e) {
Graphics g=e.Graphics;
int y=20;
for (int i=8; i<14; i++) {
Font font=new Font("Microsoft Sans Serif", i);
string s="abc,.,ghi (MS Sans Serif "+i+" pt)";
g.DrawString(s, font, Brushes.Black, 20, y);
y+=30;
font.Dispose();
}
g.ScaleTransform(2, 2);
y=y/2;
for (int i=8; i<14; i++) {
Font font=new Font("Microsoft Sans Serif", i);
string s="abc,.,ghi (MS Sans Serif "+i+" pt; scale 2)";
g.DrawString(s, font, Brushes.Black, 40, y);
y+=30;
font.Dispose();
}
}
I see what you see: on small Sans Serif, a period is a single pixel; a comma is a rectangle, width 1, height 2, easily mistaken for a period; on larger Sans Serif, a comma is really comma-shaped.
Nothing wrong here.
|
|
|
|
|
Well, to my mind, a typeface is a typeface is a typeface. If it looks one way in Word, the same font should look the same in VS or in a running Win App or Excel or wherever!
9 pt in Word seems okay to me.
Just out of interest, did you also run this under .net 2 and if so, what was the result?
Regards,
Rich
|
|
|
|
|
AFAICT 9pt SansSerif looks the same everywhere.
You have my code, you can experiment freely.
|
|
|
|
|
How to x^2+y^2+z^2=g^2 if x^2+y^2=a^2 and x^2+z^2=b^2 and y^2+z^2=c^2 in VB.NET?
Thanks.cheers!!
|
|
|
|
|
choose a single forum and stick to it!
|
|
|
|
|
By writing code...
What? You thought we were going to do your homework for you?
Project Euler has a couple of problems that are similar. You start by narrowing down the sets of numbers you have to work with.
|
|
|
|
|
Dave Kreskowiak wrote: Project Euler has a couple of problems that are similar.
Indeed. As well as much harder ones. I'm off going to tackle some more of them
|
|
|
|
|
Yeah, they are cool. I've done the first 75 of them in the last couple months, but haven't had time to look at them in the last few weeks.
|
|
|
|
|
I started last year, did almost 100 of them (using C#), created a little article[^], and decided to wait for .NET 4.0 (i.e. BigInteger); I really should start a second stint now.
|
|
|
|
|