Mike_R

Ok, quick followup: I changed the definition of "memory used" to utilize GC.GetTotalMemory(True): Class MyMemoryUsage Private _baseMemory As Long Private _usedMemory As Long Sub Init() _baseMemory = GC.GetTotalMemory(True) End Sub Sub Report() _usedMemory = GC.GetTotalMemory(True) - _baseMemory MessageBox.Show(_usedMemory.ToString("N0")) End Sub End Class And now it runs exactly as one would expect. Public Class ArrayTesterClass Shared Sub Array_MemoryTester() Dim myArray() As Integer Dim oMemUsed As New MyMemoryUsage oMemUsed.Init() oMemUsed.Report() ' <-- Reports 24 ReDim myArray(1000000) oMemUsed.Report() ' <-- Reports 4,001,964 ' Fill in values for HALF the Array : For i As Integer = 0 To myArray.Length \ 2 - 1 myArray(i) = i Next oMemUsed.Report() ' <-- Reports 4,001,964 ' Fill the other half : For i As Integer = myArray.Length \ 2 To myArray.Length - 1 myArray(i) = i Next oMemUsed.Report() ' <-- Reports 4,001,964 myArray = Nothing oMemUsed.Report() ' <-- Reports 1,948 GC.Collect() oMemUsed.Report() ' <-- Reports 1,948 End Sub End Class Sorry for any confusion, and thank you Plausibly, clearly the Environment.WorkingSet() is not a great command here (which you were repeatedly warning me about). I do wonder what it is reporting however... Anyway, problem solved. Are there any other quick commands that you can think of to help measure Memory Utilized by a Process? (Short of having to use the CLR Profiler?)

To get to a variable's Definition, you can hit the {F12} key. "Navigating Back" is {CTRL}+{-}, that is, the CTRL Key and the "Minus" Key at the same time. You can customize these hot-keys as well, although, I don't personally know how to do it...

Ok, that's interesting. I'll have to test this out a lot more thoroughly. Clearly, it makes no sense that an Array actually be allocated in segments. I thank you for your thoughts on this. I'll let you know if I figure out anything more... Thanks again :)

I see what you mean, but I think you are overstating the case. Clearly there is some variability involved, presumably due to some overhead issues. But overall, I do feel thet the figures are indicative, overwhelming the "noise" involved. I tried re-running it with multiple calls to oMemUsed.Report(), to get a feel for the variability. This variablitiy is actually only slight, when compared to the entire phenomenon: Private Sub Array_MemoryTester() Dim myArray() As Integer Dim oMemUsed As New MyMemoryUsage oMemUsed.Init() oMemUsed.Report() ' <-- Reports 0 oMemUsed.Report() ' <-- Reports 331,776 oMemUsed.Report() ' <-- Reports 344,064 oMemUsed.Report() ' <-- Reports 352,252 oMemUsed.Report() ' <-- Reports 352,252 oMemUsed.Report() ' <-- Reports 352,252 oMemUsed.Report() ' <-- Reports 352,252 ReDim myArray(1000000) oMemUsed.Report() ' <-- Reports 368,640 oMemUsed.Report() ' <-- Reports 368,640 oMemUsed.Report() ' <-- Reports 368,640 oMemUsed.Report() ' <-- Reports 368,640 ' Fill in values for HALF the Array : For i As Integer = 0 To myArray.Length \ 2 - 1 myArray(i) = i Next oMemUsed.Report() ' <-- Reports 2,371,584 oMemUsed.Report() ' <-- Reports 2,379,776 oMemUsed.Report() ' <-- Reports 2,379,776 oMemUsed.Report() ' <-- Reports 2,379,776 ' Fill the other half : For i As Integer = myArray.Length \ 2 To myArray.Length - 1 myArray(i) = i Next oMemUsed.Report() ' <-- Reports 4,378,624 oMemUsed.Report() ' <-- Reports 4,378,624 oMemUsed.Report() ' <-- Reports 4,378,624 oMemUsed.Report() ' <-- Reports 4,378,624 myArray = Nothing oMemUsed.Report() ' <-- Reports 4,378,624 oMemUsed.Report() ' <-- Reports 4,378,624 oMemUsed.Report() ' <-- Reports 4,378,624 oMemUsed.Report() ' <-- Reports 4,378,624 GC.Collect() oMemUsed.Report() ' <-- Reports 532,480 oMemUsed.Report() ' <-- Reports 544,768 oMemUsed.Report() ' <-- Reports 444,768 oMemUsed.Report() ' <-- Reports 444,768 End Sub And, again, the Task Manager reflects these movements. I follow what you say about the OS <--> App memory allocations, but there still seems to be something odd here about how this memory is being allocated. That is, unless the Environment.WorkingSet and Task Manager values really are worthless above-and-beyond this variability/overhead issue. But, as a simple place to start, the Task Manager's reported memory consumpition would seem to be a reasonable guide, no?

Ah, right! I really should have known that... thank you, Jaco. :)

Sorry for such a ludicrously n00b question... But what is the bitwise 'Not' operator in C#? In short, I'm trying to replicate this VB.Net code in C#: Dim myInt as Integer = 0 myInt = Not myInt MessageBox.Show(myInt.ToSting) ' <-- Reports -1 In C# I tried this: int myInt = 0 myInt = !myInt // <-- Compile Time Error MessageBox.Show(myInt.ToSting) But the above complains that the '!' operator does not apply for Integers. I guess it's for booleans only? So what is the easiest way to do this in C#? I can't imagine that I have to resort to a Collections.BitArray, do I? Much thanks in advance... Mike

Yes, the behavior is identical in both modes. Sorry I should have shown that. Basically almost no "allocation" is attributed from creating the Array itself. About 300K is all' date=' the rest of the array seems to Allocate Memory linearly, depending on how many values I "fill". Here is a more complete coding:Public Class Form1 Inherits System.Windows.Forms.Form Private Sub Form1_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load Call Array_MemoryTester() End Sub Private Sub Array_MemoryTester() Dim myArray() As Integer Dim oMemUsed As New MyMemoryUsage oMemUsed.Init() oMemUsed.Report() ' <-- Reports 0 ReDim myArray(1000000) oMemUsed.Report() ' <-- Reports 303,104 ' Fill in values for HALF the Array: For i As Integer = 0 To myArray.Length\\2 - 1 myArray(i) = i Next oMemUsed.Report() ' <-- Reports 2,314,240 ' Fill the other half: For i As Integer = myArray.Length\\2 To myArray.Length - 1 myArray(i) = i Next oMemUsed.Report() ' <-- Reports 4,321,280 myArray = Nothing oMemUsed.Report() ' <-- Reports 4,325,376 GC.Collect() oMemUsed.Report() ' <-- Reports 475,136 End Sub End Class Class MyMemoryUsage Private _baseMemory As Long Private _usedMemory As Long Sub Init() _baseMemory = Environment.WorkingSet End Sub Sub Report() _usedMemory = Environment.WorkingSet - _baseMemory MessageBox.Show(_usedMemory.ToString("N0")) End Sub End Class Thank you for the info on SysInternals and CLR Profiler! I downloaded the CLR Profiler, but it will take me a while to learn about it... On the other hand, I have played with Environment.WorkingSet a bit and it seems to match what the Task Manager is telling me. Exactly. Also, the behavior I'm getting above does suggest that it is reflective of the GC's actions. (Note that, in the code above, the memory does not seem to release from 'myArray = Nothing' until after 'GC.Collect()' is called.) Interesting, yeah? Or is this all "worthless" because calling Environment.WorkingSet is just useless? It's hard to believe though... it is telling me *something* no?

Ok, well... there really is nothing else. :( There is an OLE Container control, but it dates to like 1994 and is terrible, even in VB6. Generally, Excel is Automated, stand-alone. Bringing it into your form is a nice idea, but the OLE Container (which is sort-of designed to do this) really is very tough, and is more of a "viewer" than an interactive control.

Ok, this I found interesting... Basically, I took an Array of 1,000,000 Integers and checked the memory usage. The interesting thing is, I would have thought that all the memory is allocated at once, even if all the values are initialized to zero values. However, in assigning values to only half the Array, and then later the other half, I could test and see that Memory Allocation for this Array, was actually incremental: Private Sub Array_MemoryTester() Dim myArray() As Integer Dim baseMemory As Long Dim usedMemory As Long baseMemory = Environment.WorkingSet ' Allocate 4 MB of Memory: ReDim myArray(1000000) 'But only give a value to HALF of them: For i As Integer = 0 To myArray.Length\\2 - 1 myArray(i) = i Next ' Report Memory Usage: usedMemory = Environment.WorkingSet - baseMemory MessageBox.Show(usedMemory.ToString("N0")) ' <-- Reports: 2,140,000 ' Fill the other half: For i As Integer = myArray.Length\\2 To myArray.Length - 1 myArray(i) = i Next usedMemory = Environment.WorkingSet - baseMemory MessageBox.Show(usedMemory.ToString("N0")) ' <-- Reports: 4,300,000 End Sub Assigning values to the first 500,000 elements used up 2 MB. And then filling the other 500,000 elements got it to 4 MB. Given that Integers are 4 bytes each, this is mathematically correct. However, Arrays are not a Queue or a Linked List... I would have thought that an Array's memory allocation would have to be "all or nothing", no? I could see an "incremental" memory allocation occurring with an Array of Object that was Boxing Integers, but this example is Strong Typed. I just do not understand how the Memory allocation is going on here. It also can't be Boxing (or any other reference-type allocation) because the bytes used per element is almost exactly 4, there is no extra overhead involved here. Can anyone explain what is going on?

I think the best way to go for this is to use the Office Web Components Spreadsheet Control. I've not used it extensively, but it seems fine in .Net. To find it, right-click on your Toolbox, choose 'Add Or Removed Items...' and then choose the COM Tab. Then scroll down to find "Microsoft Office Spreadsheet 11.0" (or 10.0 or whatever is on your system). This control looks and acts a lot like Excel and you can bind the data to a Worksheet source or give it a SQL String to connect it to any database. It's pretty good for what you want to do, and it's pretty much the only control to do this.

Ok, glad to hear it... And I'm not surprised. Thanks for the info, Plausibly. :)

Hi guys, I'm thinking about switching over to C# from VB.Net. I'm a little disappointed, however, that the C# Text Editor for Visual Studio seems to be inferior to that of VB.Net. In particular, Syntax and Compile-Time errors are not picked up until the code is executed. Similarly, once errors are identified and fixed, the squiggly blue lines do not disappear on the fly, but instead wait until run again. Is there a plug-in/patch/upgrade to improve C#? How about a C# beta 2005 version, is this improved? I appreciate any and all feedback... Thanks :), Mike

Ok, glad you found it! :) But apparently this is a Read/Write String? Can you explain what you pass in? A new SQL String, I guess?

Ok, I found it where you said it would be. Thank you very much. :) I can see why they did this and I don't mind them hiding them. It shortens the IntelliSense list when using my own Classes, reducing the clutter. However, in this case, that they considered '.ToString' to be "Advanced" is a little silly, eh? Anyway, I thank you much for the info, it's a big help.

Ok, more nonsense... Note that the following is 1005 fine in C#: char c = 'a'; int i = c; MessageBox.Show(i.ToString()); // Returns "97" But the following chokes in VB.Net: Dim c As Char = "a"c Dim i As Integer = c ' <-- Compile Time Error MessageBox.Show(i.ToString()) The correction needed to use: Dim i As Integer = Convert.ToInt32(c) Pretty ungainly though. I wonder why they made VB "stricter" than C#? Oh well...

Yeah, anything smaller than an Integer is narrowing and so this error kicks in. :( Bytes and Shorts come to mind. Integer, Long, Single, Double, Decimal should all be fine. I guess UInt32 is a no-go because the native Integer evaluation on the right-hand side (RHS) could be negative value and so this is also narrowing. It's a bit odd, and I'm starting to get used to it. I wish there were more shortcut conversion symbols like "c" for Char and "R" for Double. A "b" for Byte would seem nice at a minimum. The truth is, codes for all values that are narrower than Int32 would seem more important than those that are wider, for the latter can rely on implicit conversion... Hmmm.... I also wonder why C# does not have a problem with Byte++ or Byte += 1, whereas these choke in VB.Net, tripping over Option Strict. I, again, suppose that the '+' operator is overloaded, but then I wish they had also overloaded VB.Net's '+' operator in the same fashion. Oh well.

Ok, my bad... I think the problem is with the '1' and not with the 'Bytes(i)' aspect. That is, '1' is being interpreted as an Integer, by default. Unfortunately, I don't think there is a "shortcut" conversion symbol for the Byte data type. That is, for example, I could do the following for Chars, or double, respectively Dim myChar As Char = "a"c Dim myDouble As Double = 1R It would make sense that Byte could make use of 'b' or 'B', but, alas, this does not work. :( I wonder how C# gets around this 'Option Strict' issue... I guess the + operator is simply overloaded to handle Byte + Integer. Then I wonder why VB does not overload their operator as well? It really seems that VB is taking this "Option Strict" a tad to far? Oh well, a bummer for VB I guess...

I was stunned to find that the following was a problem in VB.Net: Dim bytes() As Byte = {1, 2, 3, 4, 5} Dim i as Integer For i = 0 To bytes.Length - 1 bytes(i) += 1 ' <-- Compile Time Error Next The result is a squiggly blue line under the "+=" part and the error message read: This was puzzling, so just to make sure that I wasn't going insane, I tried changing the offending line to:bytes(i) = bytes(i) + 1 The result was the same error message and the squiggly line this time was under "bytes(i) +1". However, the following is just fine in C# however: byte[] bytes = {1,2,3,4,5}; int i = 0; for(i=0; i<bytes.Length; i++) { bytes[i] +=1; } Does anyone have an idea of what might be going on in the VB.Net example? It seems kind of ludicrous to have to make use of the Convert class to convert a Byte to istelf?? Thanks in advance...

I see.. I'm "implicitly" inheriting from the Object class. I had not thought about that. Thanks very much! Huh, this is odd... 'Object.ToString' does not show up under IntelliSense/AutoComplete within VB.Net, but it can be called. And it does show up as a public memeber within the Object Browser. Strange, eh? How can it be Public and yet not show up under IntelliSense?

Thanks Joe, I really appreciate it... (1) Yes, it is to be Static ("Shared"), but in my confusion over the compiler complaining/requiring that I use the 'Overloads' keyword, I tried making changes, including (a) making it a Friend Method and (b) removing 'Shared'. (No real reason for the latter, but I was willing to try anything!) (2) Ok, so you used 'Overloads' and that seems natural to you... Can you explain the mentality here? This Class is within it's own NameSpace; there should be no conflicts, I would think, and so no need for Overloads? Clearly I'm not quite understanding something (basic!) here. Could you help me out? (3) My goal for this (currently), is to create a method that can convert an Array to print out it's contents. Something that would work like this: Dim MyArray(,) As Integer = {{1, 2, 3,},{3, 4, 5}} CustomConvert.ToString(MyArray) ' <-- Returns: "{{1, 2, 3,},{3, 4, 5}}" The logic of going through this is fairly easy (and I've done it for VB6 before), do you know if I'm re-inventing the wheel here? That is, is there a .Net method that already has tis capablity? Much thanks for help on any of the above! :) Mik

Hi guys, I'm trying to make a very simple 'Convert' class. The idea is to Inherit & extend the System.Convert class, but, technically, that class is not Inheritable... Anyway, I'll "inherit" this functionality by using System.Convert when necessary... My current problem is far simpler, I can't even get on first base! My code is as follows: Friend Class xoConvert Friend Function ToString(ByVal TheObject As Object) As String End Function End Class The result of the above is a squiggly line below the word 'ToString' and the error message reads: I was puzzled by this, esp. given that the same code in C# appears to be fine: public class xoConvert { public String ToString(Object TheObject) { } } Any ideas with what I'm doing wrong here. I'm neither trying to Overload nor Shadow anything. Heck, this Class, as constructed so far, isn't even Inheriting anything... Thanks in advance :), Mike

It's the *same* within VB6, however VB6 has sloppier Scoping rules. For example: Private Sub Form_Load() Dim i As Integer For i = 0 To 30 Dim stuff, huh As String stuff = "43524525" huh = "3452345" Next MsgBox stuff 'Returns "3452345" End Sub Note that the final MsgBox returns the value for 'stuff' even though stuff is declared within a block. VB6 does not care about where a variable is declared. VB.Net is tighter with the scoping rules; witness the following: Private Sub Form1_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load Dim i As Integer For i = 0 To 30 Dim stuff, huh As String stuff = "43524525" huh = "3452345" Next MessageBox.Show (stuff) ' <-- CTE: "Name 'stuff' is not declared." End Sub Try copying the above into your VB.Net and it won't even run. You'll get a Compile-Time Error stating "Name 'stuff' is not declared." But the internals within the loop are basically the same.

The best way to know is to test it! But the answer is that the Scope of your 'stuff' variable is local to that block, but its Lifetime will persist until the Sub or Function is exited. That is, it will only be 'Dimmed' but once, even if it loops multiple times. So the 2nd time through your loop, the line: Dim stuff, huh As String will be ignored for it already has been Dimentioned, that is, allocated space on the Stack, etc. So the 2nd time through, you'll find that the value of 'stuff' will already = "43524525". You should test this yourself though to see. More interesting might be to use an Integer variable in the same manner, incrementing it each time through the loop. You'll notice that the variable is sort of "Static", in that it's value from the previous time is maintained. It will be maintained until the Sub or Function istelf is exited. (But it is not *truly* static, for a Static var maintains its value between calls to the Sub or Function.) Also note that by dimming within the block, this value is not accessible outside that block. That is, the variable's Scope is limited to within this block.

I can't seem to find it on the Web. The key line on the inside of this card reads: "Highlights of the Visual Studio .Net 2003 IDE" But Google is bust on that. Let me sort of outline some of the key aspects: (1) Tabbed Window Docking: The most obvious one is how the windows dock. Drag a window around, without releasing the mouse, and you'll see the various positions they can dock in. Release when satisfied. What's new with the .Net IDE is that if you drag towards the tabs at the bottom of one of the windows, the windows will "overlay" into the same space, where clicking on a tab activates the window. (Sorry, this is tough to describe without a picture... but I bet you've found this one already on your own...) (2) Code Snippets: Drag Text into the Toolbox window and the Snippet witl become an Icon within the Toolbox. It can then de dragged back into the Editor window whenever needed. Right-click on this Snippet to either (a) Rename it's Title or (b) Delete it altogether. (3) Window Auto-Hide: This one is tricky to find, but powerful. First dock a window to any side. It must be docked first. Then to the left of the [x] button you'll notice what looks like a Push-Pin/Tack thingy. Hover over that and the Tooltip will say "AutoHide". Click it, and the window will compress to an Icon on the side. Uses minimal space. Click on this icon whenever you want and it will slide out like a tray. But it stays docked which is nice -- that is, once it loses focus (if, say, you click within the Text Editor again) and it will close by itself. Very slick. If you prefer it to stay docked and open (that is, not AutoHide) then open it again and click the "AutoHide" Push-Pin icon again. (4) The Task List Manager shows a listing of all current syntax errors and other problems. Double click on any of them to Goto the line of code in question. You can also easily add your own Bookmarks within your code by putting // TODO comments ('TODO in VB.Net). Add something like this: // TODO: Remember to add .Dispose Code And it will show up as "TODO: Remember to add .Dispose Code" within the Task List. Double click on that, and it will take you right there. :) You can also make your own Custom *tags*. I added "Dbgg" to mine, so when I put //Dbgg: Be sure to ... it shows up in the Task List. "Dbgg" for me highlights something that I know that I need to fix, but isn't necessarily a Syntax error or something that the Compiler would pick up for me. But you can make your own tags by choosing Alt|Tools|Options... then choose the "Environment" folder and then the "Task List" choice. Type a name in the 'Name' textbox and then click the 'Add' button. And you're done! :) (5) Outlining: I'm sure you know that you can Hide/Show code with the automatic Outlining or adding your own #Region... #EndRegion blocks, but you can also simply hide any arbitrary area by choosing.... Hmmm... It does not seem to work in C#. Ok, well, in VB.Net you can (a) Select some text (b) Right-Click on it, and © choose Outlining|Hide Selection. But the truth is, this hiding does not persist between sessions, so it's of limited value. Hopefully they'll improve this for 2005. Anyway, that's most of the useful stuff... I hope that this was clear enough without pictures!

I don't wish to open up a debate/discussion regarding Obfuscators and Native Image Generators / Protectors (although Dotfuscator and Salamander, respectively, look excellent). However, the distinction between "Disassemble" vs. "Decompile" eludes me when these aspects are discussed. I'm guessing that: (1) Assembly involves the translation of C#, VB.Net or the like into IL and that Disassembly would be the reverse. (2) Compiling would be the translation of IL to native machine code by the JIT (or potentially by NGEN.exe). And Decompiling would be the reverse. Is this right? (LOL, am I close?) The terms seem to be thrown about a bit loosely in various discussions, so either I have this wrong or some of these web sites are often not being careful about which word they are using. Any help appreciated... :)