When you listed everything you checked out in post 8 you didn't mention if same Office version was installed at client. You did catch this requirement?
Yes, i did verify that even before I knew about the Interop PIAs. I am quite familiar with COM and use it all the time in my Delphi Win32 Code (not .net) and thus I knew that most likely, develping with Office 11 (2003) the code would have issue with say office 2000 or 2002. So I verified that. I also wondered if the .Net 3.5 package install on the client system would be affecting this as well. However, upon install the VisualBasic Express IDE, .NET 3.5 was installed on my system as well, so I subsequently determined that could not be the issue.
As for VB.Net (any .Net language if you wish, including C++) in general I see few problems with it. There is quite a lot of discussion and questions asked at forums like this all around the internet, but in 99.99% of cases caused by lack of knowledge and understanding. (and likely some the urge to chat/argue
) That's how I see it after reading most of the ~19000 threads here, and a lot more at other forums.
Granted. I had little patience, and I find that most forums I go to, I tend to ask questions that NEVER get any response. Even so much as an admin or moderator commenting to me that I either need to clarify my question, or that nobody really knows the answer. however, most of my frustration comes from the lack of knowledge and understanding, as you say, and I know. I began developing in .NET less than 6 months ago, so I am very new to the language. However, I've jumped from Delphi, to C++, to VBA, to perl, java, back and forth, and though my code in the "new" language (delphi is my primary) is not perfect, and often lacking the streamlined panache someone experienced with the language would write, it still works.
A Javascript applet i'm working on still works, but not exactly the way I wanted to, or the C++ modification i made to a Game DLL doesn't exactly do what I thought it should - but the fact remains they still work.
My experience with .NET has been a turbulent one, but in the end, when I've worked with other languages and platforms, when I've compiled my EXE it would run on another system with no question. Some of my 'specific' code calls might cause a glitch, but the application would still start. Compile, Copy, run - should work.
Your application has only two issues external to .Net, Office automation and Shell automation. There are some traps with Office, but I think we have resolved the basics here with Office+PIA, with working code and correct O+PIA installed at client there should be no problem with this. The Shell32 is another issue, I have no way to verify this regarding versioning. If it don't otherwise sort out you have to try without this, if not for other reason than to check it out. I did some research on the internet regarding Shell32 versioning and deployment but were not able to find anything related this issue.
As for regards to "external" issues, I do not believe these are the problems. For one, I removed all Office Interop Dependencies. Every reference to Word.Document, Word.Cell, Excel.Worksheet, Excel.Range, etcetera i converted to a generic Object. This is COM, there is not need for an Interop DLL to access COM. The interop stuff, as far as I could tell, was only providing real time type information. And you know what it worked. My computer never noticed the lack of the Interop DLLs.
As well, I removed the Shell32 Interop dll, (still keeping it included in the program references) and found the program ran, until the first time my application made a shell32 call, and then it came up with an error. This was on my system as well. So, should the problem be related to the Shell32, the error should not have occurred until later the application usage.
If the error was Office+PIA related, it should have gone away when I removed the necessity for them to be installed. (I have subsequently returned them to the application once I discovered the program still failed without them involved).
Here is my awareness of the problem.
<Global.System.Diagnostics.DebuggerStepThroughAttribute()> _
Protected Overrides Sub OnCreateMainForm()
Me.MainForm = Global.UniversalTool.UnivForm
End Sub
This is the My Project - Application.Designer.vb file. Sets the application main form to my "main form".
Public Sub New()
Me.InitializeComponent()
End Sub
this is UnivForm.New() the constructor of my form and subsequently the main interface of the application.
Public stColors As ColorTableClass
Public ClientList As ClientListClass
Public Preferences As UnivPreferences
Public ClientForm As ClientInfoForm
Public WithEvents FTPFrm As FTPForm
Public WithEvents ActiveJobs As CPMJobListClass
Private WithEvents KeyHook As WindowsHookLib.LLKeyboardHook
Private WithEvents f_Tasks As PendingTasks
Private WithEvents f_Tmp As CPMClientJobProject
My Defines in UnivForm - basically my global variables and such that are used throughout the application. These are created at start up, and they handle all the actual operation of the application. WindowsHookLib is a keyboard hook dll to interface with the Win32 SetWindowsHookEx() API function. This is a third-party DLL, but i have used it with other smaller applications else where and it has never caused a problem. To Be sure i did remove it from my code (a total of about 4 lines - New(), AddHandler, Start(), Stop()) to make sure.
Sub MainFormLoad(ByVal sender As Object, ByVal e As EventArgs)
Try
Me.Width = 1024
Me.Height = 768
Me.tm_DefColMenuCmb.SelectedIndex = 6
MainJobPage.Enabled = False
stColors = New ColorTableClass()
ClientList = New ClientListClass()
Preferences = New UnivPreferences(True)
ClientForm = New ClientInfoForm(Me)
FTPFrm = New FTPForm(Me)
ActiveJobs = New CPMJobListClass()
KeyHook = New WindowsHookLib.LLKeyboardHook()
f_Tasks = New PendingTasks()
f_Tmp = New CPMClientJobProject()
KeyHook.InstallHook(True)
ClientList.LoadTargets()
ClientForm.ClientList = ClientList
jt_ClientCmb.Items.Clear()
jt_ClientCmb.Items.AddRange(ClientList.ToArray())
FSW.Path = Preferences.JobFolder
AddHandler KeyHook.KeyDown, New WindowsHookLib.LLKeyboardHook.KeyEventHandler(AddressOf KeyHookKeyDown)
AddHandler f_Tasks.CJPItemAdded, New PendingTasks.CJPItemAddedHandler(AddressOf TaskCJPAdded)
AddHandler f_Tasks.ProgressChanged, New PendingTasks.ProgressChangedHandler(AddressOf TaskCJPProgress)
AddHandler f_Tasks.CJPProcessCompleted, New PendingTasks.CJPProcessCompletedHandler(AddressOf CJPProcessCompleted)
AddHandler f_Tasks.CJPItemRemoved, New PendingTasks.CJPItemRemovedHandler(AddressOf Me.TaskCJPRemove)
AddHandler f_Tasks.CJPListSorted, New PendingTasks.ListSortedEventHandler(AddressOf Me.TaskListSorted)
AddHandler ActiveJobs.PropertyChanged, New CPMJobListClass.PropertyChangedHandler(AddressOf PropertyChanged)
AddHandler ActiveJobs.JobFileTrigger, New CPMJobListClass.JobFileTriggerHandler(AddressOf JobFileTriggered)
AddHandler ActiveJobs.ProgressChanged, New CPMJobListClass.ProgressChangedHandler(AddressOf ProgressChanged)
AddHandler FTPFrm.OnFileDownloadEvent, New FTPForm.FileDownloadEventHandler(AddressOf FTPFileDownload)
azp_CriteriaCmb.Items.Clear()
azp_CriteriaCmb.DataSource = CriteriaLabels
azp_CriteriaCmb.ValueMember = "Value"
azp_CriteriaCmb.DisplayMember = "DupeName"
catch ex as exception
MsgBox(Ex.Message)
try end
End Sub
As you can see in my Main Form's Load() Event handler, is where I create all my objects. Everything that is "My CODE" accessing Office Interop DLLs, Creating Object List Structures, and defining all my object's event handlers, all occurs here. Nicely wrapped, I might add, in a Try/Catch handler. I had even created bunk integer variable that i manually increment at each creation line so that in my MsgBox() call I would do MsgBox(x & ": " & Ex.Message) so that I would know the last successful operation, and subsequently know where to look. In my attempts to run this application on another system, this Try/Catch block NEVER executed. If the exception was explicitly in my code at this time, I should have received the MsgBox error box describing the event. This tells me only
1 thing: The Error is not explicitly in MY code.
Therefor the error exist before the MainForm Load() event is executed. The only code that I can see, based on my knowledge of .NET, is the Constructor, and the application based initialization, and therefore, by logical deductive reasoning, the ERROR is in .NET. I didn't write the constructor or the application initialization code, so I can't trap the error to find out what it is. That is why I have some anger towards my .NET experience.
I have recently put a try/catch around the Me.InitializeComponents() call in the constructor and i will see if that works to a degree, but at the moment, though I recognize where you are coming from, saying I know my app better and should thus know what it requires, I'm saying the error isn't in my code. Or if it is, it is occurring BEFORE my code gets executed, and thus I have no way to debug. I may be wrong. I may have screwed the pooch entirely with some random line of code that I'm not thinking of. And to be honest, i've made some dumb mistakes with code in the past and end up looking rather sheepish in similar circumstances. But right now, with this simple task of taking an application I wrote and use daily, and setting it up to work on a different system, it is failing in a manner that I cannot debug. If there is a method in the application that is "application.run" or something that I can TRAP this error, i'd be getting somewhere, but I don't know .NET well enough to know where to put this exception handler so that I can SEE what the error is. InvalidOperationException is not clear enough to elucidate the glitch for me to repair. As far as i can tell, the .NET libraries on my system are not the same libraries on everyone else's - and thus I am only left with the conclusion that .NET sucks. Because of this problem I have no other recourse to turn to except the realization that I have WASTED some six months learning a language that doesn't work. I know this is not the case, and I know there is a solution. But
I can't find it.
So I come here, and say now: Ignore the Office PIAs. Ignore Shell32. What else could cause the application developed in .NET, compiled with Microsoft's VisualBasic Express, to fail
before the MainFormLoad() event is even triggered. If we answer this, the problem will no longer exist, of that I am sure. *smile*
other issues from the past: the SplitContainer component has often plagued me with the MinSize limiting property, as I have often done the math of a 500 width and set panel1 to minsize 200 and panel 2 minsize to 150, and the splitterdistances to 200, and yet the system will complain the splitterdistance must be equal or greater than the minsize. well 200 is equal to 200 in my book, but these errors DID occur at compile time, while trying to run the application through the IDE.
I do have a FileSystemWatcher on the form, could something in it be causing a glitch, such as the WatchFolder or other such specifics?
When i try to play with the VisualBasic Express, it wants to add "Handles x.event" to every one of my events, removing the "AddHandler" statements in my *.Designer.vb files. Is this better/worse than using the AddHandler methodology?
Thanks for your help, dude. I mean, i understand people like me can be frustrating and I really do appreciate the help.
Thanks
Jaeden "Sifo Dyas" al'Raec Ruiner
