EliCat

Hehe ... thought the same thing when I got the e-mail notification. :)

It is indeed a must to register Crystal Reports to deploy and package things properly because you need to add a certain registration code before you can package things properly. If you don't add that code and still deploy things you'll get some error about a keycode not being correct and won't be able to view your reports. For complete instructions on how to package CR's check out this pdf file on the Crystal Decisions site: crnet_deployment.pdf Beware as well that if you've used any patches for the CR-dll's that you'll need to run those patches as well after installing your application elsewhere. The merge modules you need for deployment (you'll read about them in the pdf-file) don't deploy the patched versions of your dll's, but instead deploy a version that's baked into the merge modules themselves, so you'll always be stuck with older dll-versions. I've just had a whole e-mail discussion with 2 ppl from Crystal Decisions about this problem with outdated dll's getting packaged and they're looking into getting this fixed properly (i.e. having the patch also update the merge modules .... don't even think about downloading new merge modules to fix this "outdated dll's" problem, they're not available *sigh*), but I think it might be a while before it actually is. Also, if you've installed your application plus a dll-patch and things still aren't working as they should, download the latest version of the patch and try installing that. On pc's running just the .NET Framework instead of the entire VS.NET design environment, the older patches may be incapable of registering the new/patched dll's so that even if you think you're using the new ones you're actually still using the old ones in your installed application. (In win2000 Pro you can easily check which version is registered by going to C:\WINNT\assembly, right-clicking on the dll you want, selecting "properties" and going to the "Version" tab and check if the version mentioned there is the same as the version of your physicall dll-file.) And on a last note ... when installing the patch it's best to be logged in while having administrator rights (at least in win2000 Pro it is). If you're not logged in with those rights it might be that even the newer updated patches can't register the new/patched dll's. That in a nutshell is 2 weeks worth of testing, trial and error and almost daily communications with Crystal Decisions. Maybe this will spare someone my recent frustrations on deploying CR's for .NET.

I've already searched high and low on the http://www.crystaldecisions.com and wherever else I could think off, but haven't found a satisfactory answer to an annoying problem. I've even unsuccessfully tried to get an answer from the C.D. staff and seeing as I've had great help on this forum in the past I figured I might try it here as a last resort. Is there a way to force merge modules to grab the proper/latest versions of the Crystal Decisions dll's from a developer system when an application is packaged for distribution? I ask because my problem is this: Visual Studio .NET installs version 9.1.9370.0 of CrystalDecisions.Windows.Forms.dll but this dll contains a known bug when it comes to printing in landscape format. On my developer system (win2000 Pro with service pack 3) that runs VS.NET I can easily fix my problem by running the cr10netwin_en.exe patch which upgrades my dll to version 9.1.9466.8. However when I package my application and use Managed.msm, regwiz.msm and DataAccess.msm to include the CR dll's the older 9.1.9370.0 version is packaged and not the newer version. On a test system (also win2000 Pro with service pack 3) which runs only the .NET Framework I can then install my application and run the cr10netwin_en.exe patch to upgrade the dll's on the test system. The upgrade of the dll's works fine (in the c:\program files\common files\crystal decisions\1.0 folder) EXCEPT that the entries in my Assembly Cache (located in c:\winnt\assembly) aren't upgraded. And because this entry isn't upgraded I am unable to automatically print my reports on the test system in landscape format. With loads of trial and error I've found a way to manually upgrade the assembly cache entries on the test system by copying gacutil.exe and gacutil.exe.config from my development system to the test system and force an upgrade of the cache entry CrystalDecisions.Windows.Forms.dll. It seems that gacutil is able to force an upgrade of the assembly cache while (at least on the test system) the cr10netwin_en.exe patch is apparantly unable to do the same. So now I can at least let our in-house testers test a proper version of the reports, but this application has to be sold commercially and I can't very well let our customers go through all those steps (not even the patching), especially not since the steps need to be repeated each time the application is (re-)installed (the installation resets all the dlls and also the entry in the assembly cache). I am therefore looking for a more permanent solution, one that lets me automatically package the correct dll's from my developer system and that lets me install our application without needing to run any CR patch or using gacutil to upgrade the cache entry. Does anyone have a clue how I can do this?

My collegue and I were looking into a similar problem and he ran across this online: http://archive.devx.com/dotnet/discussions/043002/accesscontrols.asp Maybe you can get some tips from it as well. BTW lovely signature dynamic_sysop .. congrats. :)

That's just it ... even when I filled in stuff in the AssemblyInfo.vb file I couldn't access it with Application.CompanyName etc. I have however solved the problem by using something similar to your "Dim a As ..." statement and then by walking through all the objects in my assembly file and when I find the right assembly type I associate the value of the object with my variable. Thanks for the input. Oh yeah, now that I think of it ... any idea why the copyright-object from the standard AssemblyInfo.vb file gives as type System.Diagnostics.Debuggable instead of System.Reflection.AssemblyCopyrightAttribute as it should give? Is that some sort of bug?

Can't test what you posted since I'm at home, but my main concern with that method is: where do tell my application what it's company and productname are? I already figured out the bit about Application.CompanyName etc ... but when trying to compile things I got one of those NullReference-errors (or whatever the exact text is), so I know that there's no info to be gotten. (This is why I started looking into using the AssemblyInfo.vb) I've searched high and low and while with my limited VB6 experience I can there easily find where to put that info, I haven't yet found it in .NET .... all I've found is where I can specify the ... erm ... if memory serves me the applicationname (using "Property Pages" in the Solution Explorer).

I'm starting to go bonkers here so anyone that can help this relative newbie please do so. I'm working on a splash screen for our application and while loading it I want to show: - company name - application name - application version I know I can use AssemblyInfo.vb for this but I have no idea how. The application consists of a couple of projects and the AssemblyInfo.vb file is located in project that loads first. In this project are also my Main.vb and frmSplash.vb What I had in my frmSplash.vb is: Imports System.Reflection Public Class frmSplash Inherits System.Windows.Forms.Form Public Sub SetStatus(ByVal sMessage As String) Dim test as [Assembly] test.LoadWithPartialName("AssemblyInfo") End Sub ....... (form stuff) End Class After this how do I access any of the items in the standard AssemblyInfo.vb file? Seeing as I couldn't get this to work I've also tried a different way .. now at least I can get the application version, but neither the companyname nor the application name since neither is associated with my *.exe file. My alternative splash coding is as follows: Public Class frmSplash Inherits System.Windows.Forms.Form Public Sub SetStatus(ByVal sMessage As String) Dim UtilisInfo As FileVersionInfo = FileVersionInfo.GetVersionInfo(Application.ExecutablePath) Me.lblUtilis.Text = "Versie " & UtilisInfo.FileMajorPart & "." & UtilisInfo.FileMinorPart _ & " Build " & UtilisInfo.FileBuildPart End Sub ........ (form stuff) End Class If I go this road how can I associate the company name & application name with my executable? P.S. I've browsed through this forum extensively and read everything I found about loading the assembly etc, but still don't understand one bit how to apply it, so have some patience if I ask silly questions.

Mmmmmmmm ........ I'm sure I tried that yesterday and couldn't get it to work. Did get it to work now though. I must have been struggling yesterday with the forms not being in the same project (don't ask me why that is, I'm only making additions to an application someone else made) and done something wrong there. Either that or I was braindead by the time I got to that portion of the programming. ;) Many thanks once again for making the process of learning to program with VB.NET a bit easier. ;)

Thanks that was indeed it ....... I was using Show() instead of ShowDialog(). I changed it and it worked straight away (with of course also resetting the StartPosition of my form to CenterParent instead of Manual). Since you weren't sure if you needed to specify the parent I ran a few small tests. I filled in both "Me" and "Me.MDIParent" and even left it blank and it makes no difference .. the form always loads in the same position now. Since in this case it doesn't make much difference if I have my form in CenterParent or the center of my MDIParent I'm now keeping it at CenterParent, but at least this little excercise has made me figure out how to bypass the parent if I want to connect its location to another form. ;) Thanks again And also thanks for your usefull posts all over this forum about how to work from one form on another by adjusting my constructor (I lost count of how many times you had to post the same stuff because ppl didn't bother to search the forum properly). On that note .... about this constructor business (if you don't mind). I've noticed that even if I pass over the name of form1 to form2 that from form2 I can't access any objects (buttons, listboxes, etc) on form1. At least not unless I also pass those objects into my constructor on their own. Is this the only way to make sure you have access to not only a forms properties but also it's objects (I mean without making the entire form1 public/global). I'm now already passing around 7 variables in some places and dread to see how things will look if I want to be able seperately enable/disable the various buttons on my "form1" (I've so far taken the easy option and gone for completely enabling/disabling form1 *g*)

I seem to have some weird problem with the start position of one of my forms. My forms open in this order and StartPosition 1) Mainform ... WindowsDefaultLocation 2) Reportform ... WindowsDefaultLocation and it's an MDIChild with the Mainform as the container 3) Selectform ... CenterParent; this form is opened by a button on the Reportform The way I've set the StartPosition I would think that my select form would open in the center of the report form, but it doesn't. The first time I open it it starts in a random position. If I close and then reopen it starts up in the most top, left corner and each close/open procedure after that it opens at location (x,x) where x gets increasingly larger until it reaches a certain point, then it goes back to (0.0) again and starts all over. It doesn't seem to matter to which position I drag my main+reportform (they're not full screen) ... the procedure above happens no matter what. The weird thing is if I set my Selectform to "CenterScreen" instead it works perfectly and always starts in the center of the screen. I've already bypassed the problem for this form by assigning parameters for the StartLocation (now set to Manual) before opening it and calculating them so that they open the Selectform in the center of my Mainform (instead of the Reportform), but I don't want to keep running into this problem and having to bypass it for each form I open. Am I missing something about how CenterParent is supposed to work? Or is it something that has to do with my Reportform being a MDI child?

Shoot. :( I'm constantly having trouble finding stuff in the .NET help and was hoping I'd missed something again. I already found out how to make sure MDI-forms have the proper background (since setting it in the form properties doesn't help) and was thinking there might be a way around to the other color settings as well, but there isn't I see. Guess I'll give my bosses the "good" news tomorrow. ;) Thanks for taking away any doubts I had.

I'm busy working on an application which will include some graphics on the forms. To make sure these graphics are always shown in the best light I want to fix the form colors to make sure they're always in a certain color scheme, independant of the system colors of the pc on which the application runs. I know that I can change the BackColor and the ForeColor, but those don't include items such as scroll bars, arrows in listboxes, menu items etc. Is there any way to set the colors for those items/objects as well? Thanks

Check out this thread as well about the combobox. The example posted there as attachment has helped me a lot to make a combobox that passes along several variables. http://www.xtremedotnettalk.com/showthread.php?s=&threadid=49447

REEAAAALLLLLYYYYYY great example! Thanks a bundle, this is exactly the kind of thing I was looking for. I've been slaving away all day integrating it into our application and this simple little tidbit is actually allowing me to chuck away 2 or 3 functions/subs that were being used to pass around variables and parameters all over the place. Instead of just a text and an ID I'm actually using the combo to pass around 4 different variables and because of that things are now working a lot more efficiently. All I need to do now is fill the combo from a database table (have hardcoded the data so far) and we'll be able to add modules to our application in the future without needing to adjust the coding. The guy who did the original programming is gonna be bummed that I managed to scrap so much of his work with a "simple" combobox. :)

:) I know it's supposed to be my best friend, but so far it's not really been that. Guess I'll just have to get used to how the .NET help works. (And it might help if I find the time to read at least the basic chapters in the .NET tutorial I bought the other day. *G*) Thanks for the example. I don't have .NET running at work but have downloaded the file and will forward it to work so I can look at it first thing in the morning. If I have any questions about it I'll let you know. Thanks again ... heaps :)