Mike_R

Wow, very nice description, Marble. A very neat way of looking at it. Thank you. :)

Nice list guys :)

Denaes had it right in Post #4. In computer terms, the analogy would be Serialization and Deserialization, which can be used to (a) transmit an object, (b) store and then later reconstitute an object, or © clone an object. If you make a clone, then both would feel like they are the "real Captain Kirk", and both would be right! We teleport ourselves in-place all the time. Yes, that's right, we are not static. There is some rate of molecule replacement constantly. The water in our bodies (around 90% of our mass, I think) might be replaced nearly 100% every week. Other molecules like muscle tissue might have a longer turn-around, and some molececules like calcium in our bones might take years to cycle through, but we are on a constant replacement cycle. So the only constant is not the molecules, but the "blueprint". And even the blueprint is not constant: we do age slowly. And we gain new knowledge and forget some lesser-used facts, etc. But we do "teleport in place" all the time. So if you think that a Teleport-as-Clone operation leaves the 1st person as the "real" version and the teleported person as the "clone", then you are wrong. Even if you "tag" all the molecules in the "real version" give it a couple of weeks, or maybe a year or so, and they will both be clones of the "original".

Ah, this is a really nice one, I love nonsense like this, LOL. I'm sorry I missed it. (I was away.) I have nothing intelligent to add, however. You seem to want perfect symmetry here with the pairs, so the Overloads makes sense. However, if you were willing to bend your approach slightly, you could name the accessors 'GetKey' and 'GetValue' methods instead. What's allowing you to do the reverse-lookup? Are you wrapping two Dictionaries internally within one collection?

I don't have much experience with the OWC controls, myself. They are very good looking controls, but my understanding is there might be compatiblity issues. For example, I'm not sure that if you build to version 10.0 that your code will run if the client has 11.0 installed. (I've not tested this myself, but is what I've heard, so you should test this yourself before committing to too much code here.) In general the OWC controls are being phased out (there will be not 12.0 version, for example), but Microsoft has committed to a 10 year support cycle, so I think it's fine to use them, so long as the compatiblity issue I mentioned is ok. I don't know of any tutorials here. I tried Google with weak results. But put some effort in and one should be able to find something somewhere I would think? You are using MFC, so I guess using C++ here? I don't know a thing about C++ and MFC, but in C# or VB.NET you could place the control on your form and the Interop seems to work just fine. The commands are pretty basic, using IntelliSense, you should be able to quickly find commands such as: Imports Microsoft.Office.Interop '... '... Me.AxSpreadsheet1.ActiveCell.Value = "Hello" Me.AxSpreadsheet1.Range("A1").Value = 99 CType(Me.AxSpreadsheet1.Cells(2, 2), Owc11.Range).Value = "New Value" In C# you'd use 'This' instead of 'Me' and 'Using' instead of 'Imports'. As for enabling vs. locking certain cells, you can right-click on the OWC Spreadsheet while in design mode and then choose 'Commands & Options...'. Within that you'll find all kinds of usful settings. I hope that this gets you going! :), Mike

That's strange... Do you want to attach a sample Workbook that has this property? And/or show some code that I could run to create this?

Ok, so you open the Workbook and then load an Array of data into the Range. So far so good... Then I'm confused: I don't know what you mean here? Why not? Is the sheet protected? If you want the user to be able to edit the cells, then make the Application, the Workbook and the Worsheet visible and the Worksheet unprotected (or at least the cells in question unlocked). If you wish to prevent the user from editing the cells, then hide the Application, the Workbook and/or the Worksheet or Protect the Worksheet and lock the cells in quetion. But I'm pretty darned certain that you understand all that... So I must be missing something. :( Sorry if I'm dense, if you can somehow get this through my thick skull, I can probably help... Mike

Hi Barski, Sorry, I missed this thread... I don't understand the problem? (1) The first issue seems to be compatibility across more than one Excel version. (Excel 2000 vs. Excel 2003.) If you want one set of code, you obviously need to avoid using the extra paramters available for the newer version. Binding to the lowest version probably works (it definately does in VB 6.0), but worst case, you could use one set of code, compile to, say Excel 11.0 (calling it "MyExcel11.dll") and then change the references to Excel 10.0, change and then compile, calling it, say, "MyExcel10.dll". That would DEFINATELY work 100%. (2) I didn't understand your quote here: So this was a DLL, but you needed to do it via Automation? Or by "out of process" you mean using ADO? Tell us a bit more about what you are trying to do here, something tells me that your original goal can be done, but I'm not sure 100% what you are trying to do! Can you show us a code example? (Nice link on ADO.NET with Excel and VB.NET, btw.) :), Mike

Ok, thanks guys, I appreciate it... But that wasn't quite what I was looking for. I'm sorry, I guess I was not clear on what I meant. In VB.NET (and I would assume in C# as well) a delegate cannot be defined as a Property. Only a Method can be defined as part of a delegate's signature. This means that in VB.NET a Delegate class can be defined for a Sub or a Function, but not for a Property. For example, the following is permitted in VB.NET: Delegate Function MyFunction As String while the following is not legal: Delegate ReadOnly Property MyFunction As String This would seem a bit of an odd restriction given that a read only Property and a parameterless Function are essentially the same. But I guess in general, the problem with having a Delegate that defines a Property is that most properties are Read-Write and so defining a Delegate to it would be misleading as one would actually need TWO delegates: one for 'Get' and the other for 'Set'. So restricting Delegate definitions to Methods-only really does makes sense after all... Thanks guys, Mike

Checking if the .Count = 0 should do the trick... :)

I was wondering if anyone had some thoughts on assigning a Delegate to a Property, as defining a "Property Delegate" does not seem to be allowed in VB.NET. However, since the underlying accessor methods are really just get_Property() and set_Property(value) methods, this restriction seems odd. In VB.NET, the accessor methods do not appear to be publicly exposed. Are they in C#? (I'm guessing no?) I guess I could create a Public Get and Set method pair and have those methods called by the respective Property Get and Property Set functions. But since the methods would have to be public (if I wish to assign delegates to them) it is then redundant to also have a public property doing exactly the same thing -- so I may as well throw out the property altogether and just stick with a Get and Set method pair only. I could use an interface that includes a property and then pass in a reference to the class that implements the property. This is fine, I guess, but not as flexible as a delegate, unless one is willing to make a lot of pre-defined interfaces with different property return types. A final thought is that I could use Reflection to find the property's accessor methods and then create an instance of the PropertyInfo class, which would effectively become my *Delegate*. A little ugly, but doable. Funny that I could create a "surrogate delegate" via a PropertyInfo class or via a class+interface, but directly using a Delegate class appears to be off limits to Properties... Does anyone have any thoughts or ideas on this? Mike

I should add however, some problems with .NET and Excel: (1) It is slower, period. The interop stands between your code and Excel. So the usual tricks about copying a Range to an Array then manipulating the Array and then passing back the results (instead of looping and editing cell-by-cell) are at even more of a premium. For the most part it is acceptible, but there is a cost. However, from time-testing that I've seen done from others, user-defined functions can run up to 10x slower, which is very noticable. I would therefore not use .NET if you are making a library of worksheet functions. (2) Backwards compatibility from Excel '97 through 2003 can be much harder if using .NET. Excel 2002 has PIA's available for download. Excel 2003 has them installed by default (generally). But Excel 2000 and Excel '97 don't have PIAs, so you can install them yourself, or ignore the issue and let .NET create local PIA's for you (which is what I do, and it should be fine, but I've never tried to deploy a solution using a local PIA). (3) As I mentioned above, deployment is harder. No harder than .NET is on its own, but it is a different scenario than COM DLLs. Overall, I would start with a VERY small project and then hit your minimum deployment needs with it. In other words, start with a program that has one button and when you click it, puts the word "Hello" in cell A1 of the Active Sheet. That's it. From there, get this working in all versions that you need (which is easiest if you only need Excel 2002 and higher) and try deploying it to a few client machines. I expect that you'll hit a few snags even doing this. However, once you get these minimal deployment needs working then you'll be able to program it pretty much just as you did with VB 6.0... Just my 2c! Mike

It's still largely the same. If you are using Automation, then it's really the same. If you are making a DLL Addin then you would make a DLL and expose it to COM. From there Excel cannot even know that you are using .NET behind the scenes. However, deployment ("trust" issues) can become trickier with .NET, but this has nothing to do with .NET <--> Excel interaction per se. If you are using Automation, then I would give this a read, for starters: Automating Office Programs with VB.Net / COM Interop If you are making an Addin, then the following could be of help: (1) How To Build an Office COM Add-in by Using C# (2) How To Build an Office COM Add-in by Using Visual Basic .NET (3) Creating Office Managed COM Add-Ins with Visual Studio .NET Hope this helps, I can provide more links or explain further if you need... -- Mike

Ah, ok, thank you guys, I really appreciate it! Funny place for it to put the red-squigly-underline, though. It gives every impression that my call to MessageBox.Show() was invalid, whereas it really should be underlining the word 'Run', I would think, no? Anyway, squigly-gripes aside, I thank you both for your exceptionally clear explanations. :) -- Mike

Well, I don't totally disagree with Diesel, here, the way you've written your question, it does seem imply that you might be in a little over your head. But you've got to start somewhere! Your "Debtor", "Collector" and "Account" classes all appear to be business objects (the middle layer) to me. Beyond this though, I have no experience with n-tiered applications. Since I'm about as noob as you on this, I would personally start small, create a thin-but-functional front end, then a simple class for your middle layer and then a simple database with, say, only one table to be your back-end. Starting small for starters will likely help you see the big picture as to how the full blown application should be laid out.

Please forgive me for what could bee the noob question of the year... Normally I use VB.NET, but fooling around with C# today, I couldn't even get to first base. I attempted the following code: static void Run { MessageBox.Show("hello"); } But the compiler complained about the MessageBox.Show call, complaining that: (See the screen shot below.) Can anyone tell me what ridiculously simple thing I am missing here? Thanks in advance! Mike

Thanks Marble, this is very good info. I was not at all aware of this, and had been generally appalled at the time required to throw-and-catch an exception, since I usually got times of about 0.4 to 0.5 sec's. But after testing the 1st vs. subsequent exceptions, it is clear that you are very correct. The first exception can vary all over the map, but I get anywhere from 5 ms to 15 ms when run as an EXE, and up to 500 ms (a full half second) when thrown-caught from within the IDE in debug mode. However, the 2nd and subsequent exceptions seem to be at about 0.3 ms when run as a compiled EXE, which is pretty manageable in most cases. Yes, you would not even want this kind of a hit in a tight loop, but this is not generally worth panicking about. (My PC has an AMD 2800 chip, just for reference.) I tested the same with COM Exception handling, just for kicks, and it's about 10x slower at around 3.0 ms per exception thrown-caught. This is heavier, but even this is still not a disaster. Very good food for thought, Thanks a ton ME :), Mike

Ah yes, well your caveat (your 2nd point above) is why I was looking for a non Try..Catch..Finally approach in the first place. I was hoping that something along the lines of checking the FileStream.CanWrite property could to the trick... However, the New FileStream() constructor simply fails in the first place if the file is locked, sending me back to the Try..Catch..Finally approach. On the other hand, I was shocked at how quickly this particular error seems to be thrown and caught. Maybe I'm insane, but this one seems to run lightening-fast compared to the roughly 0.5 seconds delay I get with other errors that are thrown-caught. This one seem instantaneous (to the human eye anyway), so my initial concern is essentially very small...

Hi, thinks PD, you make two excellent points: Ok, this is something that I had not thought of... So the only *real* approach then is to simply try to open whatever it is you wish to open and trap any errors with Try..Catch..Finally. Otherwise, there is a minute risk of a problem. Good pickup! Thanks PD. :)

Hi guys, I was wondering how one might test if a File is Locked without resorting to a Try..Catch..Finally block. I'm not sure if it can be done, but I was thinking that it *should* be doable? Using a T/C/F block we can do something like this: Shared Function FileIsLocked(ByVal fileFullPathName As String) As Boolean Dim isLocked As Boolean = False Dim fileObj As System.IO.FileStream Try fileObj = New System.IO.FileStream( _ fileFullPathName, _ System.IO.FileMode.Open, _ System.IO.FileAccess.ReadWrite, _ System.IO.FileShare.None) Catch isLocked = True Finally If fileObj IsNot Nothing Then fileObj.Close() End If End Try Return isLocked End Function Any thoughts on if/how this could be done without a T/C/F block? (On the other hand, this ran surprisingly fast, I'm not sure why... So it's not really *that* improtant, but I was curious if anyone had some other thoughts on this...) Thanks in advance! Mike

You need to tell the methodInfo the types of the input parameters. Try this: Dim Assm As System.Reflection.Assembly = System.Reflection.Assembly.GetCallingAssembly Dim obj As Form = CType(Assm.CreateInstance("CustomBinary.Form1", True), Form) Dim paramsType As Type() = New Type(0) {} paramsType(0) = Type.GetType("System.String") Dim Meth As Reflection.MethodInfo = obj.GetType.GetMethod("MakeString", paramsType) Dim args As Object() = New Object(0) {} ' <-- Corrected as per Marble Eater, below. args(0) = DateTime.Now().ToString() X.WriteLine (Meth.Invoke(obj, args)) You should also think about using 'Option Strict On', it will really help you out... Hope this helps! Mike [Edit: I corrected one of the lines as per Marble Eater's suggestion's below. -- MR]

Ok, cool... Yes, Excel defaults to .Visible = False unless you tell it otherwise. Strange, though, Excel should not have been visible AT ALL without this line, and you only mentioned an issue with the CommandBars? Anyway, glad you got it! :), Mike

It looks like you have the critical line commented out! That said, I would try this: mAppExcel = New Excel.Application mAppExcel.Visible = True mAppExcel.WindowState = Excel.XlWindowState.xlNormal mWrkExcel = mAppExcel.Workbooks.Add AppExcel.CommandBars(1).Enabled = True Note that the above indexes the 'CommandBars(1)' instead of 'CommandBars("Worksheet Menu Bar")'. This is simply because using '1' is language independent, while using "Worksheet Menu Bar" would only work for english-language versions of Excel. (Also, there's a tutorial here which covers some of the basics that you might find useful.) Anyway, the above should work, give it a try... :), Mike

No problem, I hope we get it! Overall, I really don't know what's going wrong here. :( Let's try this in your OnConnection() event handler: private Excel.Application xlApp; public void OnConnection(object application, Extensibility.ext_ConnectMode connectMode, object addInInst, ref System.Array custom) { MessageBox.Show("OnConnection(): entering."); xlApp = (Excel.Application)application; MessageBox.Show("Excel Version = " + xlApp.Version); Excel.Workbook wb = xlApp.Workbooks.Add(System.Type.Missing); MessageBox.Show("Workbooks.Count = " + xlApp.Workbooks.Count.ToString()); Excel.Worksheet ws = (Excel.Worksheet)wb.Worksheets[1]; MessageBox.Show("Worksheet.Name = " + ws.Name); Excel.Range rng = (Excel.Range)ws.Cells; int cc = 10; //ws.UsedRange.Columns.Count; for (int c = 1; c <= cc; c++) { rng.set_Item(10, c, "test"); } MessageBox.Show("Range.Value's have been set."); MessageBox.Show("OnConnection(): exiting."); } The above really should work! If it fails, let us know where and with what error report? I have no idea why Automation would work but an Addin using IDTExtensibility2 would fail. If the abvoe test fails, I'm thinking we'll have to look to make sure the PIA's are intalled right? But I really do not know what the issue is... I've got my fingers crossed for you! Mike

Ok, you know what... I believe that all of your code will fail if you do not have at least one Workbook open. The following is an Automation example, not an Add-in, but running this from a Windows application that references Microsoft Excel should prove that your system is running right or not: private void RunIt { Excel.Application xlApp = new Excel.Application(); xlApp.Visible = true; Excel.Workbook wb = xlApp.Workbooks.Add(System.Type.Missing); Excel.Worksheet ws = (Excel.Worksheet) wb.Worksheets[1]; Excel.Range rng = (Excel.Range) ws.Cells; int cc = 10; //ws.UsedRange.Columns.Count; for (int c = 1; c <= cc; c++) { rng.set_Item(10, c, "test"); } } The above is substantially the same as what you had, but I added the line Excel.Workbook wb = xlApp.Workbooks.Add(System.Type.Missing);If the above does not run, then there is likely a problem with your Excel installation, the PIA's or something else... -- Mike