|
If the file is bigger than 2Gb then its length cannot be stored as a 32 bit integer.
You might also want to see what the debugger says is the value in Me.m_lImageFileLength before you convert it.
Upcoming events:
* Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ...
"I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless."
My website
|
|
|
|
|
M Irshad Qureshi wrote: Private m_barrImg As Byte()
M Irshad Qureshi wrote: m_barrImg(0) = Convert.ToInt32(Me.m_lImageFileLength)
There is your problem... you are trying to store a 32-bit integer in an 8-bit byte.
|
|
|
|
|
Well spotted - I completely missed that. 
Upcoming events:
* Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ...
"I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless."
My website
|
|
|
|
|
I am hoping to get some help with this one as I am stumped.
I am writing a custom program to change local administrator account settings on a batch of computers picked from AD. In my company, we have as many as 300 servers in any given OU, and with such a large number of servers, there is always flux in their status (building, operational, decommission, etc). In order to better handle the list of servers, I want to use the Win32_PingStatus to see the disposition of the server. I have been running this in a small test environment and have run into a snag. Here are the details:
Client machine: WinXP SP2
Domain: Windows 2003 Active Directory
Servers in question: HPPC (offline) & HUNTER (online)
When I first started running the Win32_PingStatus command, I noticed that it was returning code "0" (Success) for the HPPC server. I went to a command prompt and pinged the server to make sure there was nothing else going on and it came back with an error that it could not resolve the name. After tracing the code, I saw that it was missing all of the other StatusCode numbers and going to the Success routine.
To make matters more confusing, I opened WBEMTEST to run the same query (SELECT * FROM Win32_PingStatus WHERE address='HPPC') from the same machine where I am running this application. To my surprise, there is no listing for StatusCode in the return properties on the test query.
I have searched every possible combination on Google, but have yet to find anything that references this type of false positive on this query. I am hoping someone here has some insight into what might be going on (or what I am doing wrong) as this needs to be completed by Friday (8/10/2007).
Here is the code that I am using in the function:
<br />
Function IsAlive(ByVal mServerName As String) As String<br />
Dim strStatus As String = ""<br />
Dim myConnectionOptions As New ConnectionOptions<br />
Dim myManagementScope As ManagementScope<br />
<br />
With myConnectionOptions<br />
.Impersonation = ImpersonationLevel.Impersonate<br />
.Authentication = AuthenticationLevel.Unchanged<br />
End With<br />
<br />
myManagementScope = New ManagementScope("\\" & My.Computer.Name & "\root\cimv2", myConnectionOptions)<br />
Try<br />
myManagementScope.Connect()<br />
Catch ex As Exception<br />
Return "Connect Error - " & ex.Message<br />
End Try<br />
<br />
If myManagementScope.IsConnected = False Then<br />
Return "Connect Error - Cannot connect"<br />
End If<br />
<br />
Dim myObjectSearcher As ManagementObjectSearcher<br />
Dim myObjectCollection As ManagementObjectCollection<br />
Dim myObject As ManagementObject<br />
<br />
myObjectSearcher = New ManagementObjectSearcher(myManagementScope.Path.ToString, "SELECT * from Win32_PingStatus where Address = '" & mServerName & "'")<br />
myObjectCollection = myObjectSearcher.Get()<br />
For Each myObject In myObjectCollection<br />
Select Case myObject.GetPropertyValue("StatusCode")<br />
Case 11001<br />
strStatus = "Buffer Too Small"<br />
Case 11002<br />
strStatus = "Destination Net Unreachable"<br />
Case 11003<br />
strStatus = "Destination Host Unreachable"<br />
Case 11004<br />
strStatus = "Destination Protocol Unreachable"<br />
Case 11005<br />
strStatus = "Destination Port Unreachable"<br />
Case 11006<br />
strStatus = "No Resources"<br />
Case 11007<br />
strStatus = "Bad Option"<br />
Case 11008<br />
strStatus = "Hardware Error"<br />
Case 11009<br />
strStatus = "Packet Too Big"<br />
Case 11010<br />
strStatus = "Request Timed Out"<br />
Case 11011<br />
strStatus = "Bad Request"<br />
Case 11012<br />
strStatus = "Bad Route"<br />
Case 11013<br />
strStatus = "TimeToLive Expired Transit"<br />
Case 11014<br />
strStatus = "TimeToLive Expired Reassembly"<br />
Case 11015<br />
strStatus = "Parameter Problem"<br />
Case 11016<br />
strStatus = "Source Quench"<br />
Case 11017<br />
strStatus = "Option Too Big"<br />
Case 11018<br />
strStatus = "Bad Destination"<br />
Case 11032<br />
strStatus = "Negotiating IPSEC"<br />
Case 0<br />
strStatus = "Success"<br />
End Select<br />
Next<br />
Return strStatus<br />
End Function<br />
In WBEMTEST, I am using the following query:
Select * FROM Win32_PingStatus WHERE address='HPPC'
And this is the response I get from that WBEMTEST query:
Win32_PingStatus.Address="HPPC".BufferSize=32.NoFragmentation=FALSE.RecordRoute=0.ResolveAddressNames=FALSE.SourceRoute="".SourceRouteType=0.Timeout=1000.TimestampRoute=0.TimeToLive=128.TypeofService=128
I appreciate any help that I can get on this.
One final note, I also tried these same tests on a valid machine name with the same results.
Thanks
Jonathan Tyler
|
|
|
|
|
Your code assumes that you get a StatusCode back. If the name cannot be resolved, you don't get a StatusCode, "<empty>" in CIM Studio, or Nothing in VB.NET. If you convert that back to a number, like your code is doing, you'll probably get 0. This is where you're getting the false positive from.
You can check to see if there is a value using:
For each obj As ManagementObject In objectCollection
If obj.Properties("StatusCode").Value IsNot Nothing Then
' There is an actual value in StatusCode.
' Handle this as you normally would.
Else
' StatusCode returned Nothing. This means
' the ping was never performed, so there is
' no status code.
End If
-- modified at 18:09 Tuesday 7th August, 2007
|
|
|
|
|
Thanks Dave,
I took what you said and went back to my workstation. I then placed a query in for an IP address of a known working machine.
Here is the query:
SELECT * from Win32_PingStatus WHERE Address="192.168.0.59"
And here is the result:
Win32_PingStatus.Address="192.168.0.59".BufferSize=32.NoFragmentation=FALSE.RecordRoute=0.ResovleAddressNames=FALSE.SourceRoute="".SourceRouteType=0.Timout=1000.TimestampRoute=0.TimeToLive=128.TypeofService=128
Pinging the address from command prompt:
Pinging 192.168.0.59 with 32 bytes of data:
Reply from 192.168.0.59: bytes=32 time<1ms TTL=128
Reply from 192.168.0.59: bytes=32 time<1ms TTL=128
Reply from 192.168.0.59: bytes=32 time<1ms TTL=128
Reply from 192.168.0.59: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.0.59:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
There is no resolution to handle on this one and I still received no status code. Still doesn't make any sense to me.
Jonathan Tyler
|
|
|
|
|
You cannot trust the .ToString() method of the returned object. You MUST look at the status code through the Properties collection of the object to get a valid test.
I tried the exact same thing using valid and invalid IP address. In both cases, the StatusCode was missing from the returned String, but worked perfrectly through the Properties collection.
|
|
|
|
|
With that last explanation, I tried the same thing and it fixed the problem. Thank you for the explanation. It all fell into place this time. I have some other logic problems now, but at least I saw it read a success this time from a valid host on the network.
I really appreciate it...you got me out of a jam!
Jonathan Tyler
|
|
|
|
|
No problem.
|
|
|
|
|
Hi, I have a large VB5 application that needs to be moved to .Net.
I am considering 3 options to upgrade the application.
1) Upgrading to VB6 first and then using the wizard to upgrade to VB.Net
2) Rewrite the application in VB.Net
3) Rewrite the application in C#
Does anyone have any advice for taking this application to .Net or have any experience taking a VB5 application to .Net.
Thanks
|
|
|
|
|
Take option 2 or 3. VB6 is a very different language, the upgrade tool plain does not work, nor can it.
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
The elegant approach:
1) Pick up the logic from the specs of the application or a bit of reverse engineering/study of the application.
2) Plan out the implementation in (3). 
I don't subscribe to implementing in (2). It sucks. 
|
|
|
|
|
|
Having worked with all I would go with option 3. Rewriting and then converting is going to give you a ton of errors that you may as well start from scratch. This will also give you the ability to look at .NET features to see what you can rewrite to make the program more robust and faster.
_____________________________________________
Flea Market! It's just like...it's just like...A MINI-MALL!
|
|
|
|
|
Depending on what kind of app you are wanting to make, I'd go with options 2 or 3. I usually use VB.NET because it is easy, intuitive, and quick to write. If you are going to make a robust, thorough, or big app, then go with C#. It is MUCH faster, especially with dealing with many numbers.
In summary, I personally would choose VB.NET, simply because I don't know how much better C# is. If you're a beginning or advanced programmer looking to build a medium sized or large app, use C#. If it's just a simple app, use VB.NET. It's easy and fast. Besides, usually you don't need the speed.
|
|
|
|
|
`Drew wrote: It is MUCH faster, especially with dealing with many numbers.
Since both C# and VB.NET compile to the same MSIL, there really isn't any difference. Care to back that statement up with a benchmark?
|
|
|
|
|
Well, it's not really a benchmark, but it may serve the perposes of making a point.
I have a project purchases program. Each time it loads, it goes off and gets > 45,000 records, sorts them, and conveniently displays them in a hierarchy. With C#, it doesn't matter whether you load the tables or not because each takes roughly the same time. With VB.NET, it'll take a few seconds to load the same database. Please note I coded nothing in either as Visual Studio does it all.
|
|
|
|
|
Designer generated code isn't necessarily the same. The only "proof" that would demonstrate this with any accuracy is if the database code was written by hand.
|
|
|
|
|
Dave Kreskowiak wrote: Designer generated code isn't necessarily the same.
Considering my part of the program is < 50 lines long (C#)(about 10 in VB.NET), it shouldn't matter, should it?
Dave Kreskowiak wrote: The only "proof" that would demonstrate this with any accuracy is if the database code was written by hand.
Of course it is. Is there any other way to do it?
|
|
|
|
|
There is no significant performance difference between VB.NET and C#. If you wrote two versions of the same app and one performs better than the other, then the most likely explanation is that you wrote the code differently.
I remember an example from way back when from Borland who claimed that Delphi was faster than VB and provided a benchmark that 'proved' it. But when you actually look at the code, they were comparing integer operations with floating point operations. Of course, integer operations are faster than floating point operations. Whether knowingly or unknowingly, their benchmark test was invalid.
Post your code here and I'll tell you what you're doing differently.
|
|
|
|
|
Similar to my last thread, I'd like to save the form location as well. In talking to another programmer, he said that it'd probably be a good idea to have some preventative measures (i.e.: making sure the program doesn't appear off-screen). Is there a good or bad way to do this?
|
|
|
|
|
Hi again,
Your earlier post was on size, and you can protect size with the Form.MinimumSize
property (it will refuse a Size that is less than that); just give it a reasonable
minimum with Visual Designer. You could also set a MaximumSize, but there is no need AFAIK.
As far as location is concerned, if Form.StartPosition is not set to Manual, you have no
control; and if it is, you are responsible; bad coordinates will be accepted but may put
it off-screen. So you may want to validate them, by comparing with (0,0) and
SystemInformation.PrimaryMonitorSize, assuming you only have one monitor.
With multiple monitors it gets complex easily.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/AllLanguages/General
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Unfortunately, 95% of the people that will be using this program have 2 or more monitors (yes some have 3 and 4). It may be in my best interests to leave location alone and let Windows handle that.
Someday I'll figure it out...
|
|
|
|
|
well you can save the location as a point value in your settings.
my.settings.SaveLocation = my.settings.location
where SaveLocation is your variable.
|
|
|
|
|
IIRC on a multi-monitor environment, Windows puts every Form on the "primary monitor"
by default, and that might not be what you want.
If the desktop got extended over all monitors (that's a checkbox per monitor),
and if the monitors are arranged such that they (almost) cover a true rectangle,
then it makes sense to validate a form's bounds (thats location+size) against
SystemInformation.VirtualScreen
You may want to have a closer look at the Rectangle type, in particular Rectangle.Contains().
If the desktop does not extend over all monitors, then I don't know how forms get
positioned on those non-desktop monitors. Feel free to tell me more about that.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/AllLanguages/General
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
