|
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.
|
|
|
|
|
Naerling wrote: and Microsoft decides to NOT use it for Forms
After having read the reasoning on that thread, I can see why. Can't say I like it, just that I can see the reasoning. Just for fun, how about assigning null to a valuetype?
Naerling wrote: Microsoft should have dropped it in VB4
Yes, I'm glad too that Microsoft introduced C# 
I are Troll 
|
|
|
|
|
In what way is encapsulation broken? The only problem I can see with this is that if you wanted your constructor to be private then this would ruin it for you. Other than that, normal class access rules still apply.
VB.NET just acts like you declared Dim Form1 As New Form1. So the first call to a non-shared member of Form1 causes a new instance of Form1 to be created. But then, you wouldn't normally be calling non-shared members on the class anyway, so all in all the problem is fairly limited (that is to say: if you wrote your code without knowing this quirk, you wouldn't ever find out about it, because you wouldn't be directly accessing members through Form1 but via an instance).
That is not to say that I at all agree with this. I hated this quirk in VB6 already, as it was more confusing than anything. Completely unintuitive and destructive to the idea of classes and OOP for new programmers if they see this behaviour
|
|
|
|
|
its sounds good..
|
|
|
|
|
How is ignoring encapsulation sounding good? 
It's an OO world.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
