|
shereen_shf wrote: same files paths
not necessarily. Some system files could be at different positions; your app may be at a different location (assuming different systems); user files may depend on special folders such as "Documents and Settings" which move around and vary by the Windows version.
And anyway, having it work under some conditions does not mean everything is fine. You may have disobeyed an existing rule or guideline with no adverse effects on XP, and problems on Vista/Win7.
|
|
|
|
|
It would be SO helpful if Microsoft added "Data in Error" info to this message. Then it would save hours of head scratching.
|
|
|
|
|
Just make sure the path does not exceed 260 chars.
And Windows7 paths are a bit different then xp's
Maximum Path Length Limitation
In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. [Source msdn]
|
|
|
|
|
Hello
I have an application, customers via amending Script. This application handles a message screen that lets you send any alerts in a different way to "msgbox", however this screen sometimes overlaps with the others in the application and the message can not be seen. Does anyone know why this happens and how to solve it?
Thanks...
|
|
|
|
|
When you display a Form using Show() or ShowDialog() or a real MessageBox by calling its Show() method, there are several overloads of the method; some of them accept an IWin32Window parameter, where you can pass "this" (indicating the caller's form); as a result the new form/messagebox will be owned by "this", always be in front of it, and disappear together with it (e.g. when "this" gets minimized). I recommend using such ownership all the time.
|
|
|
|
|
|
zimvbcoder wrote: this == Me (VB)
yeah, I meant you Me, not this.
Like you meant = not == which doesn't exist in VB.
|
|
|
|
|
In a case that I dealt with I had to create a hidden dummy form and set it to top most then set the message box to use the dummy form as the parent for the message box...
That will always make it come to the top.
Humble Programmer
|
|
|
|
|
Hi,
I set my culture as like the following manner
Threading.Thread.CurrentThread.CurrentCulture = New System.Globalization.CultureInfo("en-GB", False)
Dim Dt2 As DateTime = MaskedTextBox1.Text
'Dim Dt2 as DateTime=CDate(MaskedtextBox1.Text)
Dim GnQy As Object = MyDs.Tables(0).Compute("sum(grn_qty)", "itm_code='" & ThsImCd & "' and grn_date<='" & Dt2 & "'")
Getting Error Message "Cannot perform <= operation on System.DateTime and System.String"
I become tired to understand the error.
Thanks
|
|
|
|
|
I suspect that your problem is that you are asking for a DateTime to be concatenated with a string. Try changing as follows:
Dim GnQy As Object = MyDs.Tables(0).Compute("sum(grn_qty)", "itm_code='" & ThsImCd & "' and grn_date<='" & Dt2<big>.ToString()</big> & "'")
I have bolded the change.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
Why do programmers often confuse Halloween and Christmas? - Because 31 Oct = 25 Dec.
Business Myths of the Geek #4 'What you think matters.'
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
