Mike_R

Hi Tobi, To get a Named Range like "cellname", you need to know if it's a Workbook-defined Name or a Worksheet-Defined name. If it's on the Worksheet, you can get the Range as follows: Excel.Range rng = xlWS.get_Range("cellname"); Or you could acccess the Worksheet.Names collection like this: Excel.Range Rng = xlWS.Names.Item("cellname").RefersToRange; Most Range Names, however, are at the Workbook-level, accessible by all the Worksheets. In this case, you need to access the Workbook.Names collection: Excel.Range rng = xlWB.Names.Item("cellname").RefersToRange; Here are a couple of links to understand Range Names better: (1) Excel Range Name Times (ExcelTip) (2) Working With Named Ranges In Excel (CPearson) As for why you do not have a Range.get_Value() method, I don't see how that is possible... Are you sure?? Do you have a Worksheet.get_Range() method? -- Mike

Donnacha, I am pretty weak at Word and I know nothing about XML/Databasing... I wonder if your Q might be better posted in the Database / XML / Reporting Forum? Just a thought, or are you looking for a Word-specific feature here? -- Mike

I'm not that far along in my COM Interop learning, nor do I know a thing about DCOM, but hopefully I can help, maybe a little... The following two links deal with DCOM and .Net: (1) Using Web Services Instead of DCOM (MSDN) (2) Offset weaknesses of DCOM with socket (CodeProject) The first one looks more promising. If the classes are in .Net, then I think that the first article may be the ticket. On the other hand, if you really want to expose your .Net Assembly to DCOM (I guess because other components will remain Legacy, and will therefor need to be using DCOM?) then I really don't know. The following are more general COM Interop Articles that could be of interest to you: Basic: (1) Introduction to COM Interop (MSDN) (2) How to call a VB.NET assembly from VB 6.0 and vice versa (MSDN) (3) Interoperating with Unmanaged Code (MSDN) Advanced: (1) Interoperability Between .NET & Win32 (Brian Long) (2) NET Interoperability - COM Interop (Brian Long) (3) Troubleshooting .NET Interoperability (MSDN) I hope this helps... -- Mike

Well, basic Excel Automation would look something like the following. It (1) Creates a New instance of Excel.Application, (2) opens the Workbook found at "C:\My Documents\Book1.xls", and then (3) accesses Sheet1.Range("A1") and reads off it's (a) .Address, (b) .Value and © .Text: using System; using System.Windows.Forms; using Excel = Microsoft.Office.Interop.Excel; class ExcelAutomate { public static void RunExcel() { const string wbName = "C:\\My Documents\\Book1.xls"; Excel.Application xlApp = new Excel.Application(); Excel.Workbook xlWB = xlApp.Workbooks.Open(wbName, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing); Excel.Worksheet xlWS = (Excel.Worksheet)xlWB.Worksheets.get_Item("Sheet1"); Excel.Range rng = xlWS.get_Range("A1", Type.Missing); // Show Excel to the User: xlApp.Visible = true; // Return the Adddress: MessageBox.Show(rng.get_Address(Type.Missing, Type.Missing, Excel.XlReferenceStyle.xlA1 , Type.Missing, Type.Missing)); // Return the Value held: MessageBox.Show(rng.get_Value(Type.Missing).ToString()); // Return the Text as formatted in the Cell: MessageBox.Show(rng.Text.ToString()); // Close down Excel cleanly: rng = null; xlWS = null; xlWB.Close(false, System.Type.Missing, System.Type.Missing); xlApp.Quit(); xlApp = null; GC.Collect(); GC.WaitForPendingFinalizers(); } } The above is a little bit of a hassle because C# cannot handle Optional Parameters nor Properties that take a Parameter. MS Office, using COM, utilizes both, and so C# needs to use a lot of 'System.Type.Missing' values in its Method calls and needs to use Property replacements provided by the PIA such as Excel.Range.get_Value() Method instead of the Excel.Range.Value() Property, which C# cannot use. VB.Net can handle this stuff natively, so its code looks a little smoother when Automating MS Office Apps. I have a tutorial here (written in VB) that explains the basics:Automating Office Programs with VB.Net / COM Interop. Gen Getz gets into .Net Excel Automation in detail, discussing it from both a VB and C# perspective: Excel Object Model from a .NET Developer's Perspective. Hope this helps! Let us know if anything here was unclear... :), Mike

Ok, just had a look, yeah that Splitter Control does look very cool, eh? :cool: I will get into UserControls at some point, I just haven't gotten to it yet. When I'm ready, I'll be bugging you for a lession, I think. ;)

Odd... Sounds more like a Networking issue than an actual Programming problem, yeah? What happens if you print a Word document "manually" to this Network Printer?

I'm not too good with this printer stuff, but This Thread, esp. from Post #7 onward, would seem to be on-topic? The basic idea is to make use of the ActivePrinter parameter in the .PrintOut() command. The key is to use the correct String input; either using a Macro Recorder or a PrintDialog Control can get you the correct String to use. Hope this helps..!

I don't really know myself. The basics look pretty much the same, bet I can tell (without ever having actually done it.) As for Subclassing I don't know, probably essentially the same, I would guess, but I've not gone there, so I just don't know. As you know, subclassing with a UserControl.OCX in VB6 is a touchy business; either you have to be very careful how you hook and unhook, or probably best to use weak pointers... My guess is that the same exact principles may apply in .Net OCX's. However the built-in .Net UserControl events may be more suitable to simple Hook-until-terminated sort of approach, I just don't know. A lot of .Net has been improved over old VB6, recognizing problems, etc., so they may have made this issue less touchy. I think you'll have to go and give it a try! :)

This looks like a decent link: http://www.annoyances.org/exec/show/article01-010 If not what you need, then I'd Google on "CAB Writer" or "Cabinet Files", etc...

In theory, yes absolutely. The COM Interop makes this possible and generally does so seemlessly. That said, it is still generally best to stay 100% within .Net if that is possible/reasonable, and your custom ActiveX control is not behaving properly. :( So where you go from here, I'm not sure, but my advice would be to re-do it in .Net if that is at all possible/reasonable. If you wish to fix it "in place", I think you have to make sure that your ActiveX control is registered properly as well as the various sub-controls that your ActiveX UserControl is utilizing. But since it works on VB6, I would guess that they are? So it remains a mystery as to why it would fail in .Net then... but if it is a complex control, as you stated, then it will likely be a lot of work to track down where the COM Interop is failing you here. :(

Add 'oSheet.PageSetup.Zoom = False' and you should be good to go. :), Mike

Ok, so you have your own UserControl that you made with VB6 and wish to use it in VB.Net? I know it doesn't sound like fun to re-do your control from scratch, but it does sound like it's worth learning how to make a UserControl in .Net instead and re-make it. I've never done it myself, but reading about it it looks pretty straight forward, and very parallel to the procedure used in VB6. If you don't re-do it, I think you're talking about having to register your ActiveX control as well as whatever controls your ActiveX is using? I could be wrong about that, but, yes, at a minimum you could try making a new, very-simple ActiveX control and see if it works. It should, but a complex one may have special issues. Again, I'd seriously think about learning how to make a UserControl "the .Net way". As for the StipMenu control, I don't have any experience with that. You probably should post your question regarding the StripMenu within the .Net General Forum. Hope this helps! Mike

Spacy, To do this you would have to open up Excel programmatically, you can't do this remotely as you would say using ADO to read the data. Once opened, you could read the Range.Interior.ColorIndex and the Range.Font.ColorIndex. For a backgrounder on Automating/Controlling Excel, you could read here: Automating Office Programs with VB.Net / COM Interop. Let us know if we can help further... -- Mike

I don't think you can get around that realistically. Compression works by substituting values with much-shorter-length tokens (just a few bits per token) The most frequent values get the shorter tokens. The data you are adding likely is using some new values not already present in the table/dictionary, so they would need to be added to the table in addition to your data. You'd have to know where this table is and how it is setup. And then even "inserting" your data would be a very, very sensitive concept, slip on one bit and the entire file beyond the insertion point is completely corrupted. Even if this were your own compression algorithm and you therefore knew how it worked extensively, you would still find it extremely hard to insert data like this, I think. I do think the only reasonable approach is de-compress, edit, and then re-compress, I'm afraid...

Why would you want to do this? Are you trying to doctor the original Windows OS files?

You should be able to drag and drop ActiveX controls onto your .Net Form in the Designer as with any control. It will work the the COM Interop and so will run a bit slower, and it's generally better to use a .Net control instead of a COM ActiveX control... but it should work fine. Which ActiveX control are you trying to use? It sounds like it might be a control that comes with VB6?? I think it would be better to use the equivalent .Net control instead. Which control is it and maybe we can help...

Yeah, I apologize... I was being a little lazy. I really just quickly cleaned up some Macro Recorder code (VBA) and didn't bother looking up the necessary Imports statements. Looks like 3, eh?Imports Excel.XlLineStyle Imports Excel.XlBorderWeight Imports Excel.XlColorIndex Glad you got it. :)

I don't have a clue about what JavaBeans is. :( But the designer should be handling the initialization of your code when you drag your Control onto the Form. For example, when you drag a Button onto your form, the Windows Designer should create the following code for you: // #region Windows Form Designer generated code /// <summary> /// Required method for Designer support - do not modify /// the contents of this method with the code editor. /// </summary> private System.Windows.Forms.Button button1; private void InitializeComponent() { // // button1 // this.button1 = new System.Windows.Forms.Button(); this.SuspendLayout(); this.button1.Location = new System.Drawing.Point(50, 70); this.button1.Name = "button1"; this.button1.Size = new System.Drawing.Size(144, 51); this.button1.TabIndex = 0; this.button1.Text = "button1"; this.button1.Click += new System.EventHandler(this.button1_Click); } Note the key line: this.button1 = new System.Windows.Forms.Button(); Without this, the 'button' Object is Null, and would throw a 'NullException' if one tried to use it. It sounds like your ActiveX control is not getting initialized for some reasion. When you drag a new copy of your control onto the Form (you might want to test this in a new, blank project), what code does the Windows Designer produce for you? Hmmm... ok, something in your code looks funny too. Are you sure that you have your brackets right? This looks fishy to me: public class Form1 : System.Windows.Forms.Form { private LabelBean.LabelBeanClass bean; } That close bracket after declaring your 'bean' variable looks wrong, it would be ending the Class definition way prematurely, right?

To get the interior lines, you can use something like the following: Dim myRange As Excel.Range = objSheet.Range("B6:E55") myRange.BorderAround(ColorIndex:=xlAutomatic, Weight:=xlThin) With myRange.Borders(xlInsideVertical) .LineStyle = xlContinuous .Weight = xlThin .ColorIndex = xlAutomatic End With With myRange.Borders(xlInsideHorizontal) .LineStyle = xlContinuous .Weight = xlThin .ColorIndex = xlAutomatic End With Note that myRange.Borders(xlInsideHorizontal) and myRange.Borders(xlInsideVertical) will throw an exception if the myRange is only a single cell. So I would add some error handling to this... Good luck! :), Mike

Hey Sonic, Sorry I missed this one... what do you mean "boaders inside". Borders are really sort of "Interior" already, altohugh, they do show up graphically as "around". That is, Cell A1's right border looks exactly the same as Cell B1's left border, but A1's really is to the left of B1's, even if they look identical. Can you explain further what you mean/want here, or have you figured it out..? -- Mike

Ah, great job putting that all together! Nice work. And glad I could help... :)

Yeah, this really is bad. This might be the only issue though that I know of where the VB.Net setup is worse-off than the C# setup. The VS 2003 C# IDE is just awful, I don't know how you guys can stand it. The 2005 Beta however is vastly improved, pfew. :) I might even switch when it comes out... Thanks again for your help, Mike

Ok, I thought it would be something like that. Thanks Derek :)

Ok, playing around, I have been able to prove that what you are telling me is true: Using the /Obj/Release and /Obj/Debug/ folders is flawed. The problem I hit is that these folders are what you say: temp folders. The key aspect they lack is that they do not copy-in any dependency DLL's, so if I have a cascading chain of A.EXE refereces B.DLL which references C.DLL, then the chain will break, because the B.DLL within the /Obj/Release/ and /Obj/Debug/ folders will not contain copies of the C.DLL. The DLL's within the /Bin folder, however will. So I did decide to split up the Build locations to create /Bin/Debug and /Bin/Release/ manually by going into Alt|ProjectProperties... And it works great. :) I could not find any option within Alt|Tools|Options..., however, to make this the default/automatic setting though. :( But now seeing your reply, I guess it should be automatic!? I certainly wish it were! Ok, kicking this around some more... ... OMG, I don't believe it: For C# it defaults exactly as you describe. For VB.Net, they both have the same default location: "/Bin". How friggin' dumb is that? As if the C# community needs yet another reason to stay away from VB.Net, lol. Seems to be the same setup in the VB.Net 2k5 beta version as well... unbelievable. Ok, well, I thank you very much for your help. It seems that much time and effort was wasted because MSFT was being dumb. I guess I can make a template to handle this automatically in the future, as I don't see a global setting for this. Thanks again :)

Ingis, I thank you for your comments here, that was a big help. I've now opened up the Alt|ProjectProperties... ConfigurationPropreties|Build... and see that the default Output Path for both the Debug and Release versions is to the /Bin directory. So it seems that the mechanics that I described were 100% correct, but I have to give thought to your advice, that is, that the /Bin directory is the *Real Deal*. What bothers me is that using the default settings, the /Bin directory is constantly being over-written, regardless of which Build (Release or Debug) was used. I suppose I could/should split up the output paths to be /Bin/Release and /Bin/Debug, although I'm not 100% sure of the advantage of that versus directly referencing the /Obj/Release and /Obj/Debug versions. I know you told me that they are "Temp" files, of sorts, but if they are written every time, then I don't see the harm? Maybe I'm making this overly complicated, but what I like to do is to debug a new feature in the DLL before compiling as a Release Build. So I have a Solution that includes a Testing EXE that references the Debug version of the DLL. All other *real client EXE's* access the Release version. The *real clients* won't witness any change until enough testing has been done to consider the new feature fully tested, at which time I compile to a Release Build. But, if instead, the /Bin folder's DLL version is being overwritten during the debugging process (which seems to be the default setting), then referencing that version could result iin my temporarily corrupting EXE's trying to use the DLL before it is fully tested. So, do you guys think I should create separate folders within the /Bin directory, that is, /Bin/Debug and /Bin/Release, or should I simply directly reference the EXE's within the /Obj/Debug and /Obj/Release directories (which is what I currently do). Or none of the above, because maybe I'm looking at this all wrong?