|
How to set the parent form size according to the child form in mdi forms
|
|
|
|
|
In the MDI container form, subscribe to the child form's SizeChanged event:
private void NewChildForm()
{
ChildForm child = new ChildForm();
child.MdiParent = this;
child.SizeChanged += new EventHandler(this.childForm_SizeChanged);
}
private void childForm_SizeChanged(object sender, EventArgs e)
{
Form child = sender as Form;
this.Size = new Size(child.Width, child.Height);
}
Something like that should get the job done. Just adjust the "new Size(int, int)" call accordingly.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
The "nice" way of doing so is by maximizing the child-form (WindowState wsMaximized)
|
|
|
|
|
Hi all,
i have a aspx grid with checkboxes for selecting the rows. I have some rows seleted and unselected rows also. how i can display only selected rows in the selectedindex_changed event of a dropdown
Thanks
Rk
|
|
|
|
|
Can't your restrict this resultset by controlling the data sent from database? In your select clause to fill this grid, only select the checked ones from the database to begin with?
|
|
|
|
|
Hi,
there is no status for the selected row in the database . this is an aspx grid. i need to hide the unselected rows
Thanks
Rk
|
|
|
|
|
If you don't need the unchecked rows in the datagrid, you can remove them from the datagrid's source as soon as they are unchecked.
|
|
|
|
|
Dear Group,
I am new to DirectX and I am stuck in one basic scenario. So my requirement is -
I am having C# Windows Form. Now on top of that form I have to Slide one Image on top of another Image. Both Images are passed to my this translating class.
I used the concept of Sprite after going through the online Samples. But the problem is when the Sprite is moving the background is set to the color which is provided in the Device.Clear() method. I didn't find any way by which I can overcome this. There is no way to set the background image of the Device too.
I also tried using the concept of Microsoft.DirectX.DirectDraw.Surface too. PFB the code which I tried -
// Code Snippet Begin
SurfaceDescription description = new SurfaceDescription();
description.SurfaceCaps.PrimarySurface = true;
description.SurfaceCaps.Flip = true;
description.SurfaceCaps.Complex = true;
description.BackBufferCount = 1;
m_PrimarySurface = new Surface(description, m_Device);
description.Clear();
description.SurfaceCaps.BackBuffer = true;
m_SecondarySurface = m_PrimarySurface.GetAttachedSurface(description.SurfaceCaps);
description.Clear();
description.SurfaceCaps.OffScreenPlain = true;
m_ImageSurfaceurface = new Surface("MyImage.jpg", description, m_Device);
// Code Snippet End
But here the line -
m_ImageSurfaceurface = new Surface("MyImage.jpg", description, m_Device);
is giving build error without any explanation why.
So I am in a stuck state. Please Help...
Note - I have DirectX 9.0 SDK installed.
Thanks in advance...
Shubhanshu .
|
|
|
|
|
When the receiving side of this serial port is idle, this sending method works just fine...
public static void SendCommandOutTheSerialPort()
{
int Length;
int StartingPosition;
byte[] TheBytesToSend;
Length = TheCommandToTheBox.Length;
StartingPosition = 0;
TheBytesToSend = TheCommandToTheBox;
myPortPool.myPort.Write(TheBytesToSend, StartingPosition, Length);
}
In fact, the Serial port can (and will, and does) send anything just fine.
The moment the external box starts sending us data, this method apparently stops and goes into an eternal loop on the last line.
Stopping the app in debug produces not a yellow arrow on the instruction (i.e., the last one in this method) but a green one instead.
Hovering over that green arrow produces this message..
"This is the next statement to execute when this thread returns from the current function"
I do not understand what thread the debugger has in mind, because I didn't start a thread. The only thing I can think of that even strikes the thought of the word "thread" in my mind is the background event handler that is doing the receive.
Just for good measure, I've set some breakpoints in the event handler that responds to bytes received on that same serial port, and it is properly receiving the bytes from the external box.
In fact, that's how we determined that conflict that was causing this. (We made the external box go silent; never sending any data, so this app can send without any response back.)
If it makes any difference, the send method and the receive method are in different classes.
Thanks for any light on the mystery.
|
|
|
|
|
You need to split your code so that the receiving part runs in a different thread than the sending part. Try a Google search for articles on serial handling for more information.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
If this means that a thread has been started, then this is news to me.
Who started the thread which I was unaware is executing ? How do I find this out ?
Thanks for any clues.
|
|
|
|
|
No it doesn't. As I said, you need to separate the code into two threads, one for sending and one for receiving. At the moment it would appear that your code is single threaded, so as soon as your receive event becomes active, the sending code is blocked.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Aha, now that is the answer I've been after ! Thank you.
This is not a problem in embedded systems which is where I'm accustomed to just going to the metal and flipping the registers. Gag, this is ridiculously complex.
Thank you for that explanation. It is the light I've been after. Thanks.
|
|
|
|
|
C-P-User-3 wrote: this is ridiculously complex. I guess it's more because of the architecture of the PC and OS.
C-P-User-3 wrote: It is the light I've been after. Thanks. You're welcome, I wish all questions were as easy to answer.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
|
C-P-User-3 wrote: I do not understand what thread the debugger has in mind, because I didn't start a thread.
Might help to keep in mind that ALL code on a modern desktop running with a standard OS executes in a real thread.
There are embedded systems that have threads and if so then all code executes in a thread as well although it might be some sort of default thread.
An embedded system without threads can be said to be executing, at least conceptually, in a thread as well. The single thread that runs the system. However that is stretching the definition.
|
|
|
|
|
Indeed, the mystery thread which I didn't start.
(Or so I thought; at one time)
I learned a thing or two at THIS[^] place, where that author provides this very useful insight...
"...The next part is critical and not obvious. serialPort1 runs in it own separate thread behind the scenes..."
(emphasis added by me).
This was really good and useful information, as you can see how it helped me to understand why I can't send and receive at the same time.
Request: I would like some kind soul to please point me to a few example code snippets that demonstrate how I can start a thread which will send out my byte array over the serial port when the existing background serial report receiver method/thread/whatever gives it an opportunity to do so.
|
|
|
|
|
Threaded my code to send a command while the other background event handler (which, as I think I'm learning, is also in a thread) is receiving.
Changed my external box to wait half a second between sending packets.
(Half a second is a long time in this context.)
He (my C# "myPort.Write(blahblahblah)" instruction) still won't execute.
I went even further. I got my external box to receive the first set of data which my C# app sends, but never send another pack back to it, i.e., the external box was purposely not responding, just sitting there so that my app on the PC would not receive data
When that happens, my C# app on the PC will transmit either the start or stop command okay, as often as it wants; i.e., with data received event, the sending works fine.
The moment I start receiving data, I can never send any more; not even one byte.
I used the C# IDE to stop the execution.
He is at this instruction...
Application.Run(new Form1());
There is a green curved arrow in the left hand edge of the window pointing to that instruction.
Hovering over that instruction gives me a message...
"This is the next statement to execute when this thread returns from the current function"
Who arbitrates those various threads ? How do I find out which thread is currently invoked ? Where is this behavior documented ?
How does a software writer get the background serial port received data event handler to back off and let the serial port send data ?
Is this documented anywhere ?
|
|
|
|
|
Plot thickens
At other times, I use the C# IDE to force a break and I find that I have another green arrow on this instruction...
TheActivePortWeAreUsing.Write(TheBytesToSend, StartingPosition, Length);
I hover the mouse over TheActivePortWeAreUsing and I see a liitle box to click, which gives me this message a zillion times over...
Cannot evaluate expression because a native frame is on top of the call stack
Who is preventing my serial port from sending data when the received data event is occuring ?
Does anyone know a way that I can tell the received data event to get out of the way for a moment to allow the Write method to send a command out ?
|
|
|
|
|
Hi,
A serial port cannot send and receive at the same time.
There must be some kind of protocol e.g. hardware handshaking, software handshaking or some kind of software protocol.
if You don't know what protocol is used, it is impossible to to make it work.
Here is an example of a protocol that my device uses.
My port is listening and waiting for for bytes to receive.
The device sends three bytes(two address bytes and one data byte and expects to have the data byte as answer immediately.
If the device receives the data byte and checks if this was the byte sent it sends the next three bytes, until there is no more to send.
In the code snippet You can see that the port is sending in the data_received event with no problem,
that is because I know the device is not sending until I answer correct.
This is the code I use to do this.
It only works with the protocol of my device, but it shows how to implement such a protocol:
System.Timers.Timer tmrPortInt = new System.Timers.Timer(800);
comportInt.DataReceived += new SerialDataReceivedEventHandler(portInt_DataReceived);
tmrPortInt.Elapsed += new System.Timers.ElapsedEventHandler(tmrPortInt_Elapsed);
private void portInt_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
if (tmrPortInt.Enabled) tmrPortInt.Stop();
int tempAddress;
int bytes = comportInt.BytesToRead;
byte[] buffer = new byte[3];
if (bytes > 2)
{
buffer = new byte[bytes];
comportInt.Read(buffer, 0, 3);
comportInt.Write(buffer, 2, 1);
if (receiveByteList == null) receiveByteList = new List<byte>();
tempAddress = (256 * buffer[0] + buffer[1]);
receiveBytes[tempAddress] = buffer[2];
receiveByteList.Add(receiveBytes[1]);
tmrPortInt.Start();
}
}
void tmrPortInt_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
tmrPortInt.Stop();
this.Invoke(new EventHandler(Process_MachineData));
}
Regards,
Groover
0200 A9 23
0202 8D 01 80
0205 00
|
|
|
|
|
@Groover
Thanks Groover, I do indeed have control over the protocol.
On the small box that I have, (our own embedded system we made here) I can send and receive, whether that is simultaneous or not, I'll let others decide, but I don't have to check anything. So far it works every time.
I want to have the bytes from the small box flood the PC.
If you are correct, then I'm going to have to change my protocol to a start-stop-resume-stop-etc sort of scheme. Yuck; ugly.
In the absence of other advice, I will suppose that yours is correct, and write more code in the small box to do exactly as you've suggested; i.e., insert more protocol between the two systems.
|
|
|
|
|
@GrooverFromHolland
@jschell
Thanks for your input.
Here's what I have learned in the past few days.
My concept of a "thread" is clearly incomplete. This is evidently not time slicing.
My external box was flooding the serial port (on purpose, we wanted to test it to the max).
Turns out that if we continually send data to the serial port, particularly at BlueTooth speeds, the SerialDataReceivedEventHandler (hope I used the right term) apparently is invoked a whole lot more than the other threads.
i.e., there isn't a round robin tossing out invocations of threads. Evidently the hardware ints on the machine are trumping the software dispatch; that is, if I'm grasping the meaning of threads and events properly (which remains a process in mental development at the moment)
So I put in some space and the RX event handler now (apparently, from observations as a user of the code I'm writing) is proiding enough breathing space for the rest of the app to have a chance to act.
Previously, as soon as the data flood started, the entire app froze, like the buttons wouldn't even click.
|
|
|
|
|
Trying to use the split function, but one of the fields I am trying to load has "Last Name, First Name" (with double quotes around it. Is it posible to set an optionaly enclosed by parameter in the split function?
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
|
Thanks
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|