|
Hello,
I am facing a strange problem, I have launched a seperate Win Form based process with the help of Process.Start from another process.
That process just dispatched an object which actually contains .NET controls(e.g button,textbox,label,radio button etc) as information (control information I just collected from Injecting other running managed processes). After dispatching , I need to draw these controls on that process having WinForm as main window( as its form based process).
BUT THESE CONTROLS ARE NOT RENDERING ON MAIN FORM WINDOW. Main problem is having with parent control information which is not correct to me.
Take a look at Code
===================
public partial class TestController: Form, IApplicationEventsSink
{
static bool m_ControllerLoadedFirstTime = true;
ITestControl m_TakoControlHandler = null;
public Controller()
{
if (m_ControllerLoadedFirstTime == true)
{
MessageBox.Show("TAKOController called first time");
InitializeComponent();
m_ControllerLoadedFirstTime = false;
}
else
MessageBox.Show("TAKOController called second time");
}
private void Form1_Load(object sender, EventArgs e)
{
MessageBox.Show("Form1_Load");
initEnvironment();
bool bSubscriptionCreated = createSubscription();
if (bSubscriptionCreated == false)
throw new Exception(String.Format("Controller failed to create subscription with Simulator process!!"));
}
public ITestControl CreateControl(CustomControl a_CustomControl)
{
ITestControl TakoControlHandler = Factory.CreateControl(a_CustomControl);
m_TakoControlHandler = TakoControlHandler;
return TakoControlHandler;
}
private void SetProperties(CustomControl a_CustomControl)
{
m_TakoControlHandler.setPropeties(a_CustomControl);
}
public void OnProcess(CustomControl a_CustomControl)
{
MessageBox.Show("OnProcess");
ITestControl TakoHandler = CreateControl(a_CustomControl);
if (TakoHandler != null)
{
SetProperties(a_CustomControl);
m_TakoControlHandler.SetParentHandle(base.Handle);
}
base.Refresh();
base.Update();
base.Show();
}
}
while the control that I need to create and render is :
public class TestButton : Button
{
Control m_Control;
public TestButton()
{
m_Control = new Button();
}
public void SetParentHandle(IntPtr a_ControlHandle)
{
Control ParentControl = Control.FromHandle(a_ContainerHandle);
this.m_Control.Parent = ParentControl;
}
}
any body having any idea? I would be greatly obliged.
Regards
Usman
|
|
|
|
|
See [WinForms - How do I access/call methods in UI thread from a separate thread without passing a delegate?]
Generally the simplest way to do multithreading in a WinForms application is to uses a BackgroundWorker to do the processing and uses the ReportProgress mechanism to send data to the UI.
Alternatively, Invoke could also be used for inter-thread communication.
The control itself should be on the same thread as the Form.
Most other ways to do things need a deep understanding on how things works and some trials...
Philippe Mori
|
|
|
|
|
Its inter-process communication.
Thread which actually launches the WinForm process is in seperate process and runs independently the execution of WinForm process. But it just launches it and dispatches the custom object to it that's it.
Now inside the WinForm process , when object dispatched to it, this cross process thread(the thread which just came from other process) actually tries to render the controls on its main Form( the Form which actually created by this process).
Note :
I think you are right, as the thread which actually renders the controls in other process , is the thread of another process, and I have to create seperate thread inside Form process and needs to take the data from incoming thread while making the incoming thread back to its own process immediately without doing any thing.
Regards
Usman
|
|
|
|
|
Controls contain lots of low level native stuff (window handles, fonts, images etc) which are linked to their host process. I don't think you can 'rehome' them in this way. I know I couldn't find a way to make it work when I tried to host plugins for my lobby client within the main window, and that is just cross-AppDomain, not cross-process.
|
|
|
|
|
I don't really understand what you are asking here. However, if it fits your needs, you can have one process host the main window of another process, by having the former call SetParent to the latter's main windows. That would take a bit of P/Invoke, passing the second process' Handle as a parameter.
Warning: the result is mostly cosmetic, the second process would show up inside the confines of a first process' window, but they would otherwise remain two distinct and unrelated processes.
Luc Pattyn [My Articles] Nil Volentibus Arduum
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Please use <PRE> tags for code snippets, they improve readability. CP Vanity has been updated to V2.3
|
|
|
|
|
As far as I know, UI elements are attached to the process they're created on and cannot be transferred 'on the fly' to a different process. The only exception is that you can use the SetParent Windows API to show a process's main window inside another process's window. I have achieved this with little success. I don't think you can use this technique with controls though.
|
|
|
|
|
I have an unbound DataGridView control with two columns. The first one is a DataGridViewButtonColumn and the second DataGridViewTextBoxColumn. When my form is first shown the DGW is empty and the only row is the one with the * in the row header (new/empty row) When I click a cell in the first column an OpenFileDialog gets shown and when I select a file the file name is written in the second cell in the same row. This works, but the row is still marked with * and a new row isn't added.
If I edit the second cell manually, the row header is marked with the pencil sign and a new/empty row is added below. Is there a way to achieve this when I edit a cell programatically? Here is my current code:
private void dataGridView1_CellContentClick(
object sender, DataGridViewCellEventArgs e)
{
if (e.ColumnIndex == 0)
{
SelectFile(e.RowIndex);
}
}
private void SelectFile(int rowIndex)
{
if (openFileDialog.ShowDialog() == DialogResult.OK)
{
dataGridView1.Rows[rowIndex].Cells[1].Value =
openFileDialog.FileName;
dataGridView1.CurrentCell = dataGridView1.Rows[rowIndex].Cells[1];
}
}
The bearing of a child takes nine months, no matter
how many women are assigned.
|
|
|
|
|
I bought secondhand Dell Latitude it came with XP Pro installed. So I get a nasty bug just by opening a infected web page. Needed to reinstall. So call him up and he says bring it down. I figured he would just reinstall his private company disk, which he did, but this time he charged me.
So sure as sh*t mo's later I get another bug. So i say, he's just going to charge me again. So I see these reinstallation disks from Dell. I get one, put it in and it don't boot.
When I was at the shop the first time I seen him using some Chinese disk 'first' to set the bios, I presume. Is this a money maker for these guys? Sell the comps cheap but lock/bypass the bios so them and only them can reinstall.
I know these Dell disks you buy cheap online can only be used once, but the one I got was unopened and still doesn't boot, and yes I did set it to boot from cd.
So what Chinese disk was that and how do I get one?
|
|
|
|
|
You don't. You skip that pirated crap and go buy Windows off the shelf and save yourself the trouble.
|
|
|
|
|
Pirated!? what do you work for mic$$ or one of the secondhand guys?
There's nothing pirated here. The scum on the internet cost me my first brand-new comp.
So I'm broke, so I buy a cheap secondhand Dell, the scum attack again, this time I save my comp but I still need a new os. Don't even mention Linux.
Now I know this disk exists, it's a bios something, Chinese?
I bought the Dell reinstallation disk legally. It's meant for the comp it came from but those comps are probably dead, so they sell them. Like i said, they only work once.
|
|
|
|
|
If you didn't buy the disk from Dell, it wasn't legal.
The Chinese disk is FAR more likely pirated garbage than it was legal.
|
|
|
|
|
1. What does this have to do with Windows forms?
2. Quit visiting "those kind of" websites.
3. Go to Dell service center or call them home if you can and get it fixed for once and for sure.
4. Always make sure to buy recovery disk or create one as soon as you buy a new computer.
"The worst code you'll come across is code you wrote last year.", wizardzz[ ^]
|
|
|
|
|
Quote: Always make sure to buy recovery disk.
If you guy didn't criticise, instead of answering a question, you'ld probably know how to read.
It's a Windows os, so what it's a Dell comp.
Someone else help me out here. The disk I 'bought' for a the Dell with a 'WINDOWS' os, does not boot.
|
|
|
|
|
Granny2007 wrote: you'ld probably know how to read.
We do know, that's why we are asking what this question has to do with Windows Forms. You bought some junk from somewhere and it does not work; how do you expect people in a programming forum to fix it? As has been suggested before, if you bought it legally from Dell then call them up and ask them to fix it.
The best things in life are not things.
|
|
|
|
|
Wrong forum!
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
|
|
|
|
|
Excuse me for thinking you 'would be' programmers would know it all.
Now your insulting my comp? That's war.
I'll go elsewhere, thx.
|
|
|
|
|
thank YOU for leaving
I cannot remember: What did I before google?
|
|
|
|
|
Today at work a co-worker had a problem. Everywhere in the code Methods of a Form were called, but we could not find any instance of the Form. I was shocked to find out that a Public Class Form1 could be used as though all its Public Methods were Shared (and none actually was!)...
Example:
Public Class Form1
Public Sub DoSomething()
End Sub
End Class
Public Class Class1
Public Sub DoSomethingElse()
Form1.Width = 1000
Form1.DoSomething()
Form1.Text = "Hello"
Form1.Button1.Text = "Me too..."
Form1.Show
End Sub
End Class
That bit of code is totally legit in VB, even with option Strict on! Is nothing sacred anymore? 
What is also weird is that when I tried to do this at work I could not reproduce it, but now I am at home at my own computer I am able to do this. Is it a setting somewhere?
I also tried it in C#, but I could not call any Public Methods like that.
Any ideas what this might be and why Forms in VB work like that?
It's an OO world.
|
|
|
|
|
If this is about VB6 or older, I couldn't care less, as VB6 has been dead and buried for years now.
In VB.NET, your code does not compile. You would need "Form1 implements Form", and then all methods/properties in DoSomethingElse() generate compile errors.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Luc Pattyn wrote: If this is about VB6 or older
Nope, the code example I showed was VB.NET, Framework 4.0.
Luc Pattyn wrote: In VB.NET, your code does not compile.
It compiles, runs great and works as expected (the Form is called with its Width set, the Buttons Text set etc.).
I just can't get over the fact that it goes against everything I have learned about encapsulation and that .NET is right there supporting it.
Luc Pattyn wrote: You would need "Form1 implements Form", and then all methods/properties in DoSomethingElse() generate compile errors.
It gets worse....
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Form2.Something()
Form2.Button1.Text = "Hello"
Form2.Show()
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Form1.Show()
End Sub
End Class
Public Class Form2
Public Sub Something()
Me.Text = "Test"
Me.NothingIsSacredAnymore()
End Sub
Private Sub NothingIsSacredAnymore()
MessageBox.Show("Hello")
End Sub
End Class
I am starting Form1, which immediatly calls Form2.Something, without first instantiating it. Form2.Something calls a Private Sub and everything is ok. I can't call NothingIsSacredAnymore directly from Form1 though.
When I start the application I first get the MessageBox saying "Hello", then Form1 and Form2 show and Form2 has it's text set to "Test" and its Buttons Text set to "Hello".
When I click the Button1 on Form1 nothing happens if Form2 is already open. If it is not it opens Form2, but with default property settings.
It's an OO world.
|
|
|
|
|
That's because, in order to make it easier to maintain some level of backwards compatibility with VB6 when converting projects from VB6 code to VB.NET, there is a little hidden collection of instances of all your Form classes in your app. If you look under My.Forms you'll find it.
I hate it. There's no way to completely get rid of it and doing so is a bad idea because it's also tied in with other Application Framework functionality.
|
|
|
|
|
Yet another reason to use C#.
Microsoft ignoring my encapsulation is a bitch... 
It's an OO world.
|
|
|
|
|
Waw. Who would come up with "free forms"!
I had pasted the OP's code into an existing VB.NET project, and wasn't surprised it didn't compile at all, so I did not understand what the OP was on about...
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Also works on older versions of VB.NET. There's a thread on StackOverflow[^] on the subject
I are Troll 
|
|
|
|
|
StackOverflower wrote: VB6 programmers had a hard time with seeing the difference between a type and a reference to an object of that type. Form1 vs frm in your snippet. There's history for that, VB didn't get classes until VB4 while forms go all the way back to VB1. This is otherwise quite crippling to the programmer's mind
I spent about 30 minutes looking for some global variable today with no luck... Encapsulation is one of the most important aspects of Object Oriented Programming and Microsoft decides to NOT use it for Forms. I ask you, what is more crippling to the programmer's mind? 
This sort of stuff leads to very unexpected behaviour in software... Microsoft should have dropped it in VB4 
It's an OO world.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
