|
Thank you for your time, elliot.
No, I didn't. Unfortunately changing the declaration didn't make any difference. Here's how the pluginClass creates an instance of the form and puts it into a panel of the MDI form as a control:
Public Sub UpdateMDI(ByVal MDIForm As IPluginMDIForm) Implements IPlugin.UpdateMainWindow
If startedAsPlugIn = false then exit sub
m_mainform = New frmMain
With m_mainform
.TopLevel = False
.FormBorderStyle = FormBorderStyle.None
.Dock = DockStyle.Left
MDIForm.TargetControl.Controls.Add(m_mainform)
MDIForm.TargetControl.Visible = True
.Visible = True
AddHandler frmMain.ListSend, AddressOf SendList
End With
End Sub
Private WithEvents m_mainform As Form = frmMain
Public ReadOnly Property MainForm() As Form Implements IPlugin.MainForm
Get
Return m_mainform
End Get
End Property
modified on Thursday, June 17, 2010 11:18 AM
|
|
|
|
|
I'm confused......
Is;
a) frmMain generated by the pluginClass
or b) pluginClass being instanced by frmMain
[edit: change message type to question]
Dave
Don't forget to rate messages!Find Me On: Web| Facebook| Twitter| LinkedInWaving? dave.m.auld[at]googlewave.com
modified on Thursday, June 17, 2010 10:05 AM
|
|
|
|
|
Thank you for helping, Dave. And sorry if I didn't express clear enough.
The pluginClass generates an instance of the form. I posted the code into my above answer, would you be so kind as to have another look there (with respect to the thread lenght I didn't put it twice)?
Maybe my whole approach is a bit clumsy, but it works just the way I want it to. Every plugin is supposed to use a particular area in the MDI, arranged through panels and splitters. Once a plugin is called, it's forms are added the different panels as controls. With the help of the splitters the user is able to adapt the different forms (panels) to his current needs.
|
|
|
|
|
Michael,
I just setup a new forms project;
1) Created an MDI form that had a single Panel to act as the container for the plugin Form
In the mdi form load event i called a sub which created the plugin class instance;
Private Plugin As PlugInClass
Private Sub MDIParent1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
AddChildFormToPanel()
End Sub
Private Sub AddChildFormToPanel()
Plugin = New PlugInClass(Me.FormPluginContainer)
End Sub
2) Created a Plugin Class which instantiates the form and loads it into the panel of the mdiform, the class also has a sub which handles the forms event.
Public Class PlugInClass
Private WithEvents m_mainform As FormPlugin
Public Sub New(ByRef TargetPanel As Panel)
m_mainform = New FormPlugin
With m_mainform
.TopLevel = False
.FormBorderStyle = FormBorderStyle.None
.Dock = DockStyle.Left
TargetPanel.Controls.Add(m_mainform)
.Visible = True
End With
End Sub
Private Sub thePluginFormRaisedAnEvent() Handles m_mainform.ButtonPressed
MsgBox("The Plug In Form Raised An Event in the PlugInClass")
End Sub
End Class
3) Created a PlugIn Form with a single button, that raises an event when clicked.
Public Event ButtonPressed()
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
RaiseEvent ButtonPressed()
End Sub
Ran the project, the form was created and loaded into the mdiform panel.
When the button is clicked the Class happily raises the message box.
I think this is what you are trying to do, and it appears to work just fine, although i didn't use any AddHandler calls, and passed in ByRef the panel where the form should be placed in the constructor for the class.
All appears to work fine.
|
|
|
|
|
Wow... that's exactly what I'm trying to do. So at least I was on the right track somehow 
I'll sit down immediately, compare the differences and adapt my code. Let you know the result then! Thanks again - and for the big effort I'd really love to rate this advice with a double maximum
|
|
|
|
|
IT WORKS NOW 
After adapting my code to yours I found that I might have a scope issue, since Intellisense didn't show me the form's event (ButtonPressed) when I wanted to put the "Handles" clause to my equivalent of your "thePluginFormRaisedAnEvent" method. Finally my error was (which was somehow to be expected  ) a really silly thing:
The declaration of my m_mainform variable
Private WithEvents m_mainform As Form = frmMain 'not working is supposed to be
Private WithEvents m_mainform As frmMain
Would anyone guess such a silly little thing being a valley of pain?
Thank you for helping me find the right track! 
|
|
|
|
|
Happy your happy!
|
|
|
|
|
We care trying to migrate from our current VisStudio 2005 (VB) on XP to 2008 or 2010 in Win7.
In some of our early test we see that the behavior is much different.
The one that is a killer is how errors are handled.
In VisStudio IDE if you get an error it stops message.
Given code
sub forms_load ...
dim i as short = 0
i = 1 / i (error divide by zero).
i = i
end sub
If the above is executed in IDE with 2005 you get a message on the i = 1 / 0. So you can fix it.
In 2008 and 2010 it just exits the function and the form is displayed (i = i is never executed).
If you put in a Try / Catch it does catch the error.
So how can we get it to stop with the error message and not just exit the function. There must be some option that we missed.
Also do you think that we should go 2010 or just 2008 and wait to see what shakes out?
Thanks
|
|
|
|
|
Hi,
I'll assume this is a WinForms app.
1.
The way some exceptions get handled by default is different when running inside or outside Visual Studio, and can be controlled by some Visual settings. Look at menu Debug/Exceptions...
2.
You should provide local try-catch for problems you can deal with locally.
3.
If all else fails, you can provide a safety net to your entire application; it will not be good enough to catch and solve the exception and continue execution in a meaningful way, it will however signal you something is wrong and needs a code fix. You would need at least two things:
- a try-catch in your main method, which is located in automatically generated file program.vb (may be hidden a bit).
- an event handler attached to Application.ThreadException; could also be added inside the same main method.
|
|
|
|
|
Yes it is a plain Windows App.
This does not answer the question about the behavior of 2005 vs 2010.
I know that a try / catch would catch it. But why doesn't it stop with an error just like 2005.
There must be a setting or something that would make it stop the same way otherwise migration of our large apps will be extremely difficult.
|
|
|
|
|
Change the operator from / to \.
dim i as short = 0
i = 1 \ i '(error divide by zero).
i = i
That will raise an exception which you can handle.
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
I know but in 2005 it stopped with an error now it just exit the function as if nothing is wrong.
This completely changes the behavior when we are testing. There must be a setting or something to make it work like 2005.
|
|
|
|
|
Have you set Option Strict to ON?
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
No, Option Strict prevents implicit changing of types i.e. Short to Int, etc.
We do not want this on. It is not on in 2005.
There must be some setting that tells VS IDE to just exit if there is an error.
|
|
|
|
|
There must be a setting or something.
Does anyone have any ideas?
This will prevent us from moving off of 2005 since the test behavior will be so different.
HELP!!!
|
|
|
|
|
i wanna know.....
how to change monitor screen resolution from the original resolution when my application active and how to return original resolution when my application is on taskbar or close?
i'll very thz u..... 
|
|
|
|
|
You shouldn't be doing this at all. Changing the resolution is a system wide setting that, if done, affects the layout of any icons that are on the desktop and changes the resolution for all applications that are running. This is not a friendly thing to do.
If you're doing this for a game, I highly suggest using DirectX/XNA to do this instead.
|
|
|
|
|
This is a follow up to my previous posts (thanks Dave, now I'm using XML and learning Compound Documents)
mydata.mdb file is 12MB, converted to mydata.mdf it is 7MB, and converted to mydata.accdb it is 1.9MB! Combined with encryption benefits of .accdb (see http://www.everythingaccess.com/tutorials.asp?ID=Changing-the-encryption-type-in-Access-2007[^]) I have every reason to want to use Access 2007 in VB 2005.
I have hard-coded the connection string as |DataDirectory|\mydata.accdb, which works fine in debug mode. I am also able to code settings so that i can change connection strings for debug and for exe modes. However, i don't seem to be able to get the connection string for .accdb when the application is published. I am lost because I dont see where the .accdb file is placed when i publish the application... (.mdb & .mdf is easily placed in the DataDirectory folder so the connection string still works) This means I also can't install the application because 'I doubt' if the .accdb file is part of the application any more after it is published.
Could someone please let me know if VS 2005 takes the .accdb file as part of the application when published; and how to create the connection string to keep this connection. I am currently using click-once, but i will be happy to know if another way of publishing the application is what I need. Please provide guideline if so.
Revolutions are brewed!
modified on Wednesday, June 16, 2010 6:23 PM
|
|
|
|
|
|
Thanks, Dave.
I went through that pain of database not updating, which is actually the database in datadirectory folder being replaced and many issues around it over 2 years ago. I sorted this out and gave some comments to other users.
Currently, I have this new 'excitement' that Access 2007 is nearly 10x smaller than Access 2003, which i think is quite good for software that client can download online.
However, when you use access 2007 in vs 2005, the accdb does not get listed in the Application Files of the project properties. that is where my problem is. I think this means it will not be picked by the publish procedure, because when i publish using click-once there is no datadirectory folder created in the setup folders, and there is no database visible anywhere in the setup files. I thought there is a way of making accdb be 'seen' by vs 2005 (as datafile) and have it included as a datafile...?
|
|
|
|
|
Pardon my ignorance on this, but I haven't used Acces for anything in years. I use SQL Server Express for everything where someone else would use Access.
But, I would try adding the .accdb file explicitly. Right-click the Project in Solution Explorer, Add Existing Item... Then you should be able to tag it appropriately in the Properties window.
|
|
|
|
|
Dave, you don't know that you are "jesus"! 
This casual comment you made just got me the solution: Right-click the file (.accdb) > Click Properties. I did this with the other access 2003 databases and noted the differences in their properties with access 2007. The next thing to do is simply change Build Action to Content (which I guess means data container or data file), and Copy to Output Directory to Always!
Just to reiterate why I needed this to work: my.mdb is 11.8MB; my.mdf is 7.2MB, and my.accdb is 1.9MB! Plus a link i provided in this earlier thread indicates that it may take a dedicated super-computer over 1000hours to break a .accdb with enhanced encryption. Read in that link.
Thanks, Dave.
|
|
|
|
|
Hi all,
I made a library to be used by MS Excel 2000 running on a number of computers under different Windows Versions (NT, 2000 Prof., XP), and some of them don't have ANY .net framework installed yet since it hasn't been needed for other purposes. From the information I had before, it seemed that I would have to register my dll with regasm on every computer before I could use it. As a consequence I would have to install the .net framework on each machine, just to allow Excel recognize my assembly.
After an experiment I figure now that it seems to be possible to deploy a pre-produced .tlb file as well - Excel called my dll properly on that particular computer. So I might probably save the whole regasm story as well as the installation of the .net framework.
Does anyone here know if I can take this experimental success for real? Or am I running into any registration (or other) trouble later?
Thank you in advance,
Michael
|
|
|
|
|
Michael Schäuble wrote: From the information I had before, it seemed that I would have to register my dll with regasm on every computer before I could use it.
Yes.
Michael Schäuble wrote: As a consequence I would have to install the .net framework on each machine, just to allow Excel recognize my assembly.
If you wrote it in VB.NET, you have no choice but to install the corresponding .NET Framework.
Michael Schäuble wrote: After an experiment I figure now that it seems to be possible to deploy a pre-produced .tlb file as well - Excel called my dll properly on that particular computer. So I might probably save the whole regasm story as well as the installation of the .net framework.
Nope. The .TLB (type library) file is just the COM registration info. It doesn't contain any executable code. You STILL have to install the .NET Framework to run the Add-In code you wrote in VB.NET and you still need the .DLL file you built.
|
|
|
|
|
Too sad...  Still thank you, Dave.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
