
Mike_R
Avatar/Signature-
Posts
316 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Events
Articles
Resources
Downloads
Gallery
Everything posted by Mike_R
-
Hey Derek, Just curious: it seems that the VS 2005 Beta version uses the W'XP Styles by default, but not the VS 2003 version. Is there a simple setting or property to have this take effect for 2003, or is it a complex procedure or install of some sort?
-
I was hoping that someone could explain the difference between the Assemblies found in the /Bin Directory and the /Obj Directory? The /Obj Folder seems pretty clear: It has /Debug and /Release sub-folders and contains the EXE or DLL according to my Build settings. But what Assembly is in the /Bin Directory? It seems to have the same size as the Release version, yet there is a .pdb file present, which would be for a Debug version. I suppose that my best guess is that the /Bin Directory holds whatever build type (Release or Debug) that was most recently built? (And if the most recent build was a Release Build, I guess any .pdb's that are present are not deleted.) But this is pure guesswork on my part; I was hoping that someone could tell me what is going on. Related is: in what way I should be using the /Bin folder (if at all)? That is, I currently Reference the DLL in the /Obj/Debug Folder for Testing & Debugging the project, but DLLs & EXE's that use it are referencing the /Obj/Release version. This makes sense to me, but I'm open to any advice, esp. if or when I should be considering the /Bin version in all this. Thanks in advance! :), Mike
-
Printing Excel Problems
Mike_R replied to SonicBoomAu's topic in Interoperation / Office Integration
If you look at the help files for the Worksheet.PrintOut() command, you'll see that there is an optional ActivePrinter parameter. I had to use the Macro Recorder to figure out what string to pass, but for my machine the correct argument was:WS.PrintOut(ActivePrinter:="HP LaserJet 1200 Series PCL 5e on Ne01:") Hope this gets you going! -
Printing Excel Problems
Mike_R replied to SonicBoomAu's topic in Interoperation / Office Integration
Ok, if I understand this right, you are considering using:xlApp.Dialogs(xlDialogPrint).Show instead of the more typical: xlApp.ActiveSheet.PrintOut Do I understand this right? This will force you into a SendKeys() situation for sure. But since it looks like you were headed this way more or less anyway, I guess it couldn't hurt. It wouldn't be my first choice though. -
Printing Excel Problems
Mike_R replied to SonicBoomAu's topic in Interoperation / Office Integration
I guess that you are trying to print to a PDF or something? If that is the case, then I believe you can set the Printing preferences in acrobat distiller to handle this without a user-prompt. The other way to go is to use SendKeys. It's an ugly kluge of an idea, but in a pinch it can get the job done. I've seen it necessary in print situations like this when the settings could not be pre-set properly. Let me know if you are using Acrobat or some other printer driver that can be pre-set. If not, then SendKeys("{Enter}") may do the trick. -
Ah, thank you very much! Still waiting for the "Full Beta" version to arrive by mail... but it's turning into a long wait! This is a big help. Thank you! :)
-
Hmmm.... ok, there's one last thing that bothers me with the above... A call to BaseClass.Union() or DerivedClass.Union() could be misleading in that each could handle both BaseClass or DerivedClass inputs. I think you'd want to create a Shadow version of Union() within the derived class. It really only needs to call the BaseClass.Union() method, but at least the Argument Signature would be checking the inputs "at the door". I think then, the DerivedClass should now look something like this: Class DerivedClass Inherits BaseClass Shared Shadows Function Union(ByVal obj1 As DerivedClass, _ ByVal obj2 As DerivedClass) _ As DerivedClass Union = DirectCast(BaseClass.Union(obj1, obj2), DerivedClass) End Function Overrides Sub Append(ByVal item As ItemClass) ' This Overrides version CHECKS for Duplicates and does not ' add the Item if it already exists: If Not MyBase.Exists(item) Then MyBase.Append(item) Else ' Do nothing, or Throw an Exception (up to you). End If End Function End Class Now the Argument signatures look like: BaseClass.Union(BaseClass, BaseClass) DerivedClass.Union(DerivedClass, DerivedClass) Hopefully this will do it! :)
-
I think the key for you is to have your DerivedClass.Append() Method 'Override' the BaseClass.Append() Method, instead of using 'Shadows'. The Static Union() Method cannot be overridden of course, but if the Append() Method is overridden, when the Union() Method() calls Append() it will be automatically calling the correct version of Append() that you want. I apologize for the use of VB code in the following, but the idea is that if your Append() Method uses overrides, you could then call: Dim BC1, BC2, BC3 As BaseClass BC1 = BaseClass.Union(BC2, BC3) And that SAME Union() Method could also handle: Dim DC1, DC2, DC3 As DerivedClass DC1 = DerivedClass.Union(DC2, DC3) Here's a sort of stub-ed out version of what I had in mind: Class ItemClass ' Arbitrary Class that the BaseClass will Hold. ' Your Classes may simply hold Int's or other basic data ' types, but I made this just to be 100% clear. End Class Class BaseClass Implements ICloneable Function Clone() As Object Implements System.ICloneable.Clone ' Note: "Me" in VB.Net is "this" in C#. Clone = Me.MemberwiseClone End Function ' Note: "Shared" in VB.Net means "static" in C#. Shared Function Union(ByVal obj1 As BaseClass, _ ByVal obj2 As BaseClass) _ As BaseClass ' ---------------------------------------------------------- ' Note that this Method is Strong Types As 'BaseClass'. ' However, the BaseClass can be safely casted to/from any class that ' derives from it. ' ---------------------------------------------------------- ' Make a duplicate of obj1, called 'newObj1'. Dim newObj1 As BaseClass = DirectCast(obj1.Clone, BaseClass) ' Append all Items in obj2 to the 'newObj1'. For Each item As ItemClass In obj2.Items newObj1.Append(item) ' <-- If obj1 is a DerivedClass then Next ' this becomes an Overridden call. ' Return the result : Return newObj1 End Function Overridable Sub Append(ByVal item As ItemClass) ' Standard Append, do not check for duplicates. End Sub Function Items() As ItemClass() ' Return an Array of Items() held by the BaseClass. End Function Function Exists(ByVal item As ItemClass) As Boolean ' Returns True if the item already exists within the Items(). End Function End Class Ok, the above does not implement .Append(), .Items() or .Exists(), but it sounds like you already have that. :) (And I don't know your exact implementation anyway.) But the point is that once this is all set up, you can have a DerivedClass lean on the coding that is within the BaseClass. It would only need to Override the Append() Method: Class DerivedClass Inherits BaseClass Overrides Sub Append(ByVal item As ItemClass) ' This Overrides version CHECKS for Duplicates and does not ' add the Item if it already exists: If Not MyBase.Exists(item) Then MyBase.Append(item) Else ' Do nothing, or Throw an Exception (up to you). End If End Function End Class I hope this was clear... :), Mike
-
Reading excel color information into VB.NET
Mike_R replied to Antoine's topic in Interoperation / Office Integration
Unfortunately, color in Excel is very poorly done. Techincally, you can utilize the Range.Interior.Color property to get the RGB value for the BackColor and Range.Font.Color property for the ForeColor. However, Excel does not *really* use RGB and so trying to use the .Color property almost always creates a mess. What you have to do in Excel, is to utilize the .ColorIndex Property, which Set/Get's a value 0 to 56 from the Workbook's color palette. xlRng.Interior.ColorIndex will Set/Get the BackColor index and xlRng.Font.ColorIndex will Set/Get the ForeColor Index. Now what do these Index values map to? Well, if you open Excel and choose Alt|Tools|Options... and then the Color Tab, you'll see the Pallette. And you can customize these colors as well. Customization is nice, but is also the source of the trouble when using RGB. If you or the User has customized any of these values, Excel seems ignorant of these changes when effecting the .Color property. That is, if you give a RGB value of RGC(255,0,0) which is pure Red, Excel will find the closest match within the Color Pallette and execute that ColorIndex value. So far so good... The problem is that if one has customized/changed the Red cell to be Blue, then passing in .Color = RGB(255,0,0) will return that same Color Index value! And -- you guessed it -- the result will be Blue! So, use Range.Interior.ColorIndex and Range.Font.ColorIndex when dealing with Excel Color, but be aware that each Workbook can have it's own customized Color Pallete, so it's best to utilize this on a Workbook that has a known color palette. I hope this made sense! :), Mike -
You know, I didn't know how to get it... I know they hand these things out at MSFT Events, but I didn't know you could order it. But I found the link: Ordering the Visual Studio 2005 Beta. It looks free, but then they tack on $8.50 for S&H, as you said. But from your enthusiasm, it sounds like it's worth it! Let us know how SharpDevelop works out... I'll let you know how the Full Beta goes. Based on my experience with the Beta Light ("Express") version, I think the Full Beta should be phenomenal.
-
Yeah, I've tracked down the C# 2005 Beta "light" version since my last post, above. The C# 2005 Beta is very nice. The VB.Net version is also really nicely improved. But it is a "light" version. Most notably you cannot compile to a Release Build -- which is very reasonable given that it is free! But there are some, I don't know, maybe 10% or so of the "usual" features missing. Not obvious at first, but enough to drive you a bit crazy... Anyway, I guess a die-hard could use the beta version and use the CSC.exe console-based compiler, but there are fewer debugging tools and the like as well. The new features such as a very nice Help File system and the C# Text Editor behaving very smoothly is all very nice, but overall, I find the 2003 "full version" better. Without a doubt though, these new features are very nice and when 2005 is a "full version" it will be very nice. (I can't wait. :)) So, overall, since this is a Beta, and is a "light" version, I am going to guess that the answer to your question is "No". It seems to install as a completely new side-by-side version as Visual Studio 8.0 (versus 7.0 for 2003) and using the .NET Framework 2.0 instead of 1.0 (for 2002) or 1.1 (for 2003). I think we have to wait. :( But I wonder about #Develop I've not given this a try, but I have heard some good things here and there. Given how clunky the Visual Studio 2003 C# Text Editor is, it might be worth a shot...
-
why unable kill Excel process?
Mike_R replied to dapanther's topic in Interoperation / Office Integration
There really are only 3 basic mechanisms: (1) Use Marshal.ReleaseCOMObject() (2) Use GC.Collect() (3) Use Process.Kill or the like Version 3, using Process.Kill or the like is brutal, and I would never use it if at all possible. Version 1, using Marshal.ReleaseCOMObject() is, technically, the correct way to go, but it is almost impossible to use in practice. You must call it on absolutely every COM Object that you access. The problem is that it must be used on all COM Objects that you access, not just the COM Object Variables that you utilize. Technically, it is possible to do right, but the resultant code is very awkward and I feel that it is virtually impossible to make a medium-scale or larger project that does not have a mistake somewhere. And if you do, there is no way to track it down... :( Version two is the way to go. You call GC.Collect explicitly, but only after all your COM Object variables hove been set = 0, or have gone out of scope. So the end of your routine might look something like this: wdApp.Quit wdApp = Nothing GC.Collect If you have other Document Objects or the like, then you must set those variables = Nothing as well before calling GC.Collect. It is critical that all COM Object Variables are Set = Nothing before calling GC.Collect. The good news is that other routines using local object vars, will have had their local vars go out of scope already. So you don't have to worry about those. (Ignoring local-scoped objects in other routines is a luxury that you cannot afford if using the Marshal.ReleaseCOMObject approach.) Anyway, give the GC.Collect approach a try. I think it will work... Fingers crossed...! -
Problems with releasing COM-Objects
Mike_R replied to Scott's topic in Interoperation / Office Integration
It sounds like to me that the company that makes this needs to make a .LogOff() method. Maybe you should suggest it? It shouldn't be very hard for them -- basically whatever they have in their Class_Terminate() Event would need to be put within this .LogOff method, that way it could be called explicitly, directly. I'm sorry couldn't do better... :( -
Problems with releasing COM-Objects
Mike_R replied to Scott's topic in Interoperation / Office Integration
Ok, I slightly mis-understood... So this object is preventing your own App from closing down?? That is pretty amazing, as well as distressing. :( I'm stunned that neither Process.Kill nor Application.Exit allowed your routine to exit. Can you kill it "manually" from the Task Manager?? Or does it simply hang for eth 40 mins you were talking about (or until you reboot)? I think I'm running out of ideas though... -
It's pretty easy in principle. Basically, you make a Standard Project type (a WinExe is fine) and then Save and Exit out of the IDE. Then open up your MyApp.vbproj file using a Notepad (or any other text editor) and modify the line stating: OutputType = "WinExe" to read: OutputType = "Library" Then change the startup object from: StartupObject = "MyApp.Form1" to be: StartupObject = "" I would give this article a read, it looks like it covers it in very good detail: How to make a DLL with VB.NET Standard Edition (DevCity.net). [Edit: I'm too sloooooow. Even better that Derek has enabled a broad set of templates, wow....]
-
Problems with releasing COM-Objects
Mike_R replied to Scott's topic in Interoperation / Office Integration
Well it sounds like you are doing everything right. You are calling Marshal.ReleaseComObject() on both relevant objects and getting a confirmation that the reference count = 0. Yet it fails... :( It doesn't look to be the case, but are either of these Methods actually functions returning an Object?: objLogin.Login("", "") objLogin.ValidateUser("Module.ABC") I'm sure not, but I had to ask... if either does return an object, then that would cause a hang (believe it or not). Well, you've tried everything it seems the only thing I can think of is to throw everything at it at once: Sub MySub() Dim objLogin As ACDB.Login Dim objRuntimeSession As ACDB.RuntimeSession objLogin = New ACDB.Login objLogin.Login("", "") objLogin.ValidateUser("Module.ABC") objRuntimeSession = objLogin.RuntimeSession Marshal.ReleaseComObject(objRuntimeSession) Marshal.ReleaseComObject(objLogin) objRuntimeSession = Nothing objLogin = Nothing GC.Collect() GC.WaitForPendingFinalizers() GC.Collect() GC.WaitForPendingFinalizers() End Sub If this fails, then the only other idea I have is to make use of the Process.GetProcessByName() method and then call Process.Kill. Very ugly, but this may be the only way if we can't get it to release via normal COM Interop commands... -
I don't think KeyPress has a Cancel argument? Ok, you can use 'e.Handled = True'. There's still a problem in that the {Tab} key seems to be handled before the Keypress ever arrives at the control and therefore moves focus to the next control without any Control_KeyPress() events firing at all. I think you need to either: (1) Set the .TabStop properties for the Controls in question = False, or (2) Set the Form.KeyPreview property = True, allowing you to trap/process the {Tab} keys there. I think that idea #1 is easier to implement though.
-
Problems with releasing COM-Objects
Mike_R replied to Scott's topic in Interoperation / Office Integration
This can be tricky/stubborn stuff. I find that the 'Marshal.ReleaseComObject()' command to be tricky at best. It doen't do any good unless you use it for absolutely every COM Object that you use and it's very easy to slip up and miss one. I find that it's easier to code normally and then if you have a COM Object or Resource, say called "MyCOMObject", then it might look like this: MyCOMObject.Close ' Or .Quit or whatever is required. MyCOMObject = Nothing CG.Collect If really a stubborn case, you can try this: MyCOMObject.Close ' Or .Quit or whatever is required. MyCOMObject = Nothing CG.Collect GC.WaitForPendingFinalizers() GC.Collect() GC.WaitForPendingFinalizers() Good luck, I have my fingers crossed for you..! -
A quick follow up... I just tested on the VB.Net 2005 Beta, and the Outlining is preserved in the 2005 version. :) I would assume the same for C# 2005, but I've not tried...
-
I'm having trouble finding any usefull Tutorials... I think the thread you are looking for might be this one: http://www.xtremedotnettalk.com/showthread.php?t=82454 The code therein confuses me however, for: (1) There is a WindowEvents_WindowCreated() Event that Handles WindowEvents.WindowCreated, howevever, there is no 'WithEvets' variable or AddHandler contruct that is calling it. (2) It looks like the following should generate a RTE, for myWindow = Nothing when myWindow.Count is accessed: Dim myWindow As Window While myWindows.Count > 0However, I know almost nothing about VS Macros, and so maybe I just don't understand how they work? Not sure. Hope this helps...
-
Well, it does look like in the end that the Task Manager and Environment.WorkingSet() were giving invalid results, as PlausiblyDamp was trying to warn me... :( Retesting with GC.GetTotalMemory() shows the correct result: the Array allocates in one-shot, as should be expected. The only way that an Array would "allocate as used" would be if the Array held a Reference Types, that is, Objects. In this way, the Array would commence as an Array of Null Pointers and the Objects would allocate as the instances were created. So if a Game or the like were using Objects, then yes, it could "allocate" linearly. However, if one wishes to "allocate as you go" like this, then it's probably better to explicitly use an ArrayList or Dictionary, as these object structures are really ment for this.
-
Actually, you could just use the PlaySound API. There may be built-in .Net methods as well (I don't know) but PlaySound works fine: Private Declare Function PlaySound Lib "winmm.dll" Alias "PlaySoundA" _ (ByVal lpszName As String, ByVal hModule As Long, ByVal dwFlags As Long) As Long Private Const SND_ASYNC As Integer = &H1 Private Const SND_ALIAS As Integer = &H10000 Then call: Call PlaySound("C:\\Windows\\Media\\Tada.wav", 0, SND_ASYNC Or SND_ALIAS) :), Mike
-
Do you know if there a Beta of this somewhere that we can upload/plug-in to Visual Studio? I find the 2003 version almost unusable. :(
-
Wow, that's a huge help. :cool: Thanks a ton...
-
Nice info Diesel, thank you. :) Would you also know how you save such customized settings? That is, if I wanted to port such settings to another PC or even just have a backup copy somewhere in case they get erased from a re-install or something?