Subpanel call.

Currently I am running a subvi in a subpanel. I want to be able to run the subvi in the subpanel only when I select a boolean control on the front panel. Is this possible? I have attached the main vi. I tried putting the code in a case structure and control it with a boolean control, but it crashed. Also, in my while loop I will need to obtain read data from some analog input channels, is this possible.
-David
Attachments:
Bla.vi ‏39 KB

Hi David-
One way to perform this efficiently is to use event-driven programming with an Event Structure in LabVIEW. The reason your VI crashed when just polling a boolean every time and executing code based on the state of that control is likely that you were running the "Open Reference..." sequence many times on the same VI. This can't work because once a VI is opened you can't open it again.
Check out the file "toplevel.vi" in the .llb I have attached here. It shows how to use events to ensure that the code is only executed when a change on the front panel control takes place.
I hope this helps-
Tom W
National Instruments
Attachments:
Load Subpanel with Events.llb ‏48 KB

Similar Messages

Creating dynamic subpanel

Hi all,
I would like to create a probe that will take in a cluster that consists of a path to a vi and some flattened data. The vi pointed to is going to be loaded in to a subpanel on the probe, and knows how to unflatten the data (which is passed to it by the probe) to display it in a more useful way. Well that is the idea, but I am having trouble trying to realise this goal. I'm using LabVIEW 7.0.
Does anybody have any idea how I could implement this idea?
Thanks,
Adrian

You seem to be mixing and mashing multiple concepts, so that's probably why you're confused.
Subpanels are a way of embedding the front panel of a VI inside the front panel of another subVI. Basically, you create a reference to a VI and pass that reference to the "Insert VI" method of the subpanel. When you're done you use "Remove VI" to remove the VI from the subpanel. Examples ship with LabVIEW to show you how to use them (Help->Find Examples).
The flattened data business is a way of setting the values of controls of a VI that you intend to call dynamically. The subpanel calls a VI dynamically. You can set the values of the controls for the subVI before the executing the "Insert VI" node of the subpanel in case the subVI has some inputs that you want to set. One of the examples for subpanels that ships with LabVIEW shows this, but the example uses the control reference's "Value" property. This is similar to the flattened data.
You started out by saying you wanted a custom probe. That's fine, as a custom probe can be a VI. Simply right-click on a wire, and select Custom Probe. Walk though the questions and specify you want a VI. LabVIEW will create a simple VI with an input control that is of the same datatype as the wire you had selected. You can do anything you want in the VI that gets created. If you want a subpanel, go for it.
Most of this stuff is actually in the LabVIEW documentation and looking at the shipping examples can help tremendously. If you provide more specific details about what you're trying to accomplish, a more specific answer can be provided.

Possible bug with Notes (in Mail) with copy / paste

Has anyone else experienced this...
From time to time the copy / paste does not work properly. When I copy some text with command-c & place the insertion point at the end of line somewhere else in the document & press command-V, the text will be inserted in the line above.
I am not certain of the precise pattern to reproduce the bug, but try this...
1) Open an existing note document within mail...
2) Copy several lines of text & paste somewhere else in the document
3) Then type some text at the end of one of these lines
4) Highlight & copy that text
5) Move insertion point to the end of the next line
6) press command-v
7) Text does not get pasted to the right location, but to the line above
I running Lion 10.7.2
Thanks

No, each of the two subpanels calls a different VI. Try it!
"Satans Little Helper" wrote in message
news:[email protected]..
> Are both your subpanels calling the same VI that contains the 3D
> graph, or are you using two separate VI's? If your subpanels are
> sharing the same sub-VI, then that sub-VI should be made re-entrant
> executable.

HT200066 Possible bug with pedals?

I am having a problem with Mainstage ever since version 3 came out.
I have three sustain pedals coming in.
They are being transmitted to Mainstage on midi channel 1.
They are sending cc#s 64 66 and 67 respectively.
I create a channel strip that is being sent to an external midi instrument
on any midi channel other than 1.
In the assignments and mappings window, I assign the pedal that is coming
in as cc66 to cc64.
The external instrument will sustain, but it does not get an off value of
zero when the pedal is released!
If I create an IAC bus and send that channel strip to a stand alone
instrument, Kontakt for instance, then open the Midi Message Monitor
window, this is what I see –
It appears that Mainstage is not sending the pedal off (0) to the external
channel (bus) on the correct channel. Instead of sending it to
midi channel 14 it is going to midi channel 1.
Can anyone confirm if this is a bug? Can you please check it yourself?

No, each of the two subpanels calls a different VI. Try it!
"Satans Little Helper" wrote in message
news:[email protected]..
> Are both your subpanels calling the same VI that contains the 3D
> graph, or are you using two separate VI's? If your subpanels are
> sharing the same sub-VI, then that sub-VI should be made re-entrant
> executable.

Snd Write Waveform.vi not run on Suse platform

in lvsound.so, VI 'Snd Write Waveform.vi'
Configuration : LabVIEW 7.0
OS : Suse 9.3
Alsa v 1.0.8 and 1.0.9
This function makes LabVIEW to exit!
It works perfectly with RedHad 9.0, XP and MacOSX
The behaviour is different between source and executable :
- source : no trouble before executing this VI
- exe : the main application loads and runs as expected.
As soon as it launches a subpanel calling this subVI it makes LabVIEW to quit.

Hi,
I have reproduced this problem and have been trying to figure it out for
a few hours now. It seems to happen on LabVIEW 7.0 only for SuSE 9.2
and 9.3 (both kernel 2.6 based), when running the SO Config.vi.
I have something for you to try. Please replace the file lvsound.so in
the LabVIEW resource directory (usually /usr/local/lv70/resource) with
the attached version.
On my system, this avoids the crash, which appeared to be caused by a
problem in the system pthread library trying to unwind the stack during
pthread exit. (The sound library uses threads to asynchronously
read/write data to the sound device.)
Regards
David D.
AE - NI France
Attachments:
lvsound.zip ‏7 KB

Possible Bug with Tree

The example on tree node removal on
http://www.adobe.com/devnet/flex/quickstart/working_with_tree/
seems to have an error.
If you remove nodes from either Finance or Operations nothing
bad occurs but if you delete one of the nodes in Engineering an
then close that folder Flash will report an error and the tree will
cease to function. On the other hand if you remove one node in
Engineering, open or close one of the other folders and then close
Engineering the error will not occur.
I've been using the Tree component on a project and keep
getting that same error and so far don't know a way to fix or
circumvent it... Help would be great!
Tiago

No, each of the two subpanels calls a different VI. Try it!
"Satans Little Helper" wrote in message
news:[email protected]..
> Are both your subpanels calling the same VI that contains the 3D
> graph, or are you using two separate VI's? If your subpanels are
> sharing the same sub-VI, then that sub-VI should be made re-entrant
> executable.

Calling a subpanel, pops up in own window instead of sub panel when there is an error

Hi all. I am working on my first real LV project for my company, and I am having some problems. The main one right now happens when I am trying to call a subVI into a subpanel. It shows up in the subpanel just fine when the program starts, but when there is an error in the error handler it skips over the invoke method and pops my subVI in its own window. Anyone have an idea on what I am doing wrong? I have included a picture of how I am trying to populate the subpanel.
Attachments:
subpanel.jpg ‏59 KB

robot_mower_guy wrote:
but when there is an error in the error handler it skips over the invoke method and pops my subVI in its own window.
I assume you have an error handling case in your state machine. So if an error happens in your error handler, you will have be passing that error around the shift register. Yes, that will mean that the invoke node ot insert the VI will not run due to the error. You need to handle your error from the error handling state.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Call by reference into a subpanel won't execute called VIT with a loop

LabVIEW experts check this out....
I've attached a sample program (Main VI.vi) that simply calls a VIT by reference (Subpanel3 VI.vit). The template simply adds two numbers, but the front panel does NOT show up if there is a loop in the template. If the loop is removed, everything works fine and of course the template runs fine standalone. You can verify this by removing the loop, then resaving the template that is called.
Is this a bug or am I missing something?
TR
><><><><><><
Tommy R.
><><><><><><
Attachments:
callByReference.zip ‏15 KB

Hello <<-N->>
In the above example, it is not possible to interact with the subpanel when the 'Wait Until Done' flag is set to TRUE because of how the run VI invoke node is wired to the subpanel invoke node. In this setup, the subpanel invoke node cannot run until the run VI node has finished due to the error wire and VI reference wire that come from the output of the run VI invoke node. Basically the subpanel is waiting on that data before it can run, and if you select the 'Wait Until Done' to be true, then the VI wont continue executing until the VI that was called is finished running. You can refer to this page for help better understanding program dataflow: http://www.ni.com/gettingstarted/labviewbasics/dataflow.htm#Wires
I've attached a picture of how you would construct the VI to be able to interact with the subpanel, while still setting the wait until done flag to TRUE. Note that the subpanel invoke node does not have to wait on the Run VI invoke node before it can run. (This is modified from the Simple Subpanel.VI in the example finder).
I hope this helps!
-Nathan H
Software Developer
National Instruments
Attachments:
subpanel_control.JPG ‏96 KB

Calling a VI in a subpanel with parameters inside an event structure and using an abort button

Hi all,
I have a control panel with a tab control and two tabs have a sub panel in them. At runtime I load the VIs I want in to the sub panels. In the control panel event structure I want to start each of the VIs and monitor the execution state so I can abort the VI while it is running. One method I use can run the VI and the abort event will work (see example). The second method I use does not and this is what I want to do! I have many inputs to the VI I want to pass so placing the VI in the event blocks everything else and it has to wait until the VI has completed, so I cannot monitor the execution state.
I have attached an example of what I want to do.
Any help appreciated.
Martin
Solved!
Go to Solution.
Attachments:
SubPanel.lvlib ‏2 KB

Hello,
You can do this with queues.
The main vi and subpanel vi's should be based on the producer/consumer (events) and you handle the front panel events accordingly in the respective vi's.
Name the queues in obtain queue , for example the Main being MainQ, subpanels SubPanel1Q, SubPanel2Q. When you start the application, initialise the main vi and also run both of the subpanels (just to make sure that the queues are first obtained by themselves). Then you can use obtain queues to do inter vi communication.
For example if you need to send data from main to subpanel1, use obtain queue and use the name SubPanel1Q, pass the required data & command and voila. Subpanel1 vi will receive your message. You can do this anyway you want. Hope this helps.
Beginner? Try LabVIEW Basics
Sharing bits of code? Try Snippets or LAVA Code Capture Tool
Have you tried Quick Drop?, Visit QD Community.

Exporting front panel of subVI to calling VI

Is there a way to "export" the front panel of a subVI so that it becomes part of the (or a pane of) the calling VI? If so, what is it called? I don't know the right language to search for examples of this concept.
My problem is as follows:--
I built a nice, classy interface to a test program that allows the user a great deal of flexibility in controlling the parameters of the device under test and in seeing the impact of those parameters on other parameters. This has about 8-12 control objects, some of which are also wired to act as indicators so that changing one can display on another and vice versa. This interface and its supporting program is big enough that it belongs in its own subVI rather than in the main program. In addition, I built another interface that charts signals from the device under test; this is also big enough that it belongs in its own subVI.
I would like to have the front panels of both of these VIs be part of the front panel of the main program. That is, the front panel of the main program should "inherit" the front panel of each subVI wholesale. If I need to tweak the interface of one of the subVIs -- for example, to add, delete, or replace controls, indicators, displays, charts, etc. -- I would like to be able to do this without having to wrestle with the main VI and the connector pane between it and the subVI.
It seems that LabView should be capable of this, but I cannot find any help, guidance, pointers, etc., in the documentation, textbooks, or examples.
Could someone give me a clue?
Thanks,
Hugh Lauer

So I tried to configure a subpanel, and found it very confusing. It seems that when you put a subpanel control on the front panel, you have to then set up a way to invoke the subVI. Since my subVI has some inputs and outputs on its connector pane, I created a VI reference for it and wired that to the type specifier node of the Open VI Reference node. I then inserted a Call VI by Reference node, so that I could wire up the inputs and outputs of my subVI. Finally, I wired this to the subpanel Invoke Method (Insert VI).
This is different from the examples I found. In those cases, the subVIs had no inputs or outputs on their connector panes, but rather took all of their information from their front panels.
I got different behavior on different attempts to run it. The most common (and most recent) behavior is that the subVI front panel opens up a few seconds after the main VI starts, but it is not quite "in" the subpanel. Instead, it is offset about an inch from both the top and left, as if it were a floating window that I cannot move. Also, it has annoying scroll bars on the bottom and right, which I don't want.
Incidentally, I have two of these subVIs, and I have not yet tried to put the second one into a subpanel.
What I would really like to do is
have both subVIs populate their respective subpanels as soon as the main VI starts, but before any work gets done.
after both subpanels are loaded, run the two subVIs in parallel, one to control the device under test and the other to capture its signals.
have no scrollbars in the subpanel windows.
In fact, what would be the best from a GUI point of view is for the two subpanels to be permanently part of the front panel of the main VI.
Any guidance or insight would be most helpful.
REgards,
Hugh

How can I put a subpanel inside another subpanel?

Hi,
Is it possible to put one subpanel o several subpanels inside one main subpanel?
Thanks,
ToNi.

DFGray wrote:
You can create something in LabVIEW to do this, but it won't be trivial. Here are some things to point you on your way. I have not done this, so it is pure speculation on how I would go about solving this problem.
You will need to know ahead of time the maximum number of windows you will want. On your front panel, create that many individual subpanels. You can hide the border and make them transparent so you never see them unless something is in them.
When you load a VI into the subpanel, all you get is the panel, not the title bar. You will need to create a title bar with buttons and any border you want on the VIs in the panel area. This is tedious, but fairly straightforward, especially if you use system colors to make it look like a real title bar/border. You won't be able to make it look like an XP title bar unless you use bitmaps/picture control. If you go that route, you can probably even mess with the color map to change the bitmap colors when the system color changes (have to poll, no event for system color change).
You can resize and move the subpanels using property nodes. Getting the info to do this could be tricky, however, since you may be coordinating mouse events from the top level VI and the VI hosted in the subpanel. Should be doable, though.
One other method is to use floating windows, but move them on top of your main window so it appears to the user it is an MDI. You won't get clipping, but everything else will look the same and you won't have to jump through hoops to create title bars, etc. You will have to write a position manager to maintain the window positions, but that is probably easier than the tricks I discussed above
Good luck. One final question - do you really need an MDI? Floating windows with clear labels are a lot easier. Do some polling of your users to find out what they like best, then go for it.
You should using windows reparenting functionality through windows api dll calls. Reparenting is documented well on microsoft.com. Reparenting is how Excel opens multiple worksheets inside the Excel "parent" window. I have done this on a few of projects and it works far better than subpanels because it allows you to drag windows around within a parent application. They are also far easier to work with once you get the reparenting vi's correct (you have to do some messing with Z position and window activation to get them to repaint properly) because unlike with subpanels you can view a VI diagram while it is reparented with no problem. With subpanels I have also had problems with GUI controls driving event structures when a vi is in a subpanel.
-Devin
I got 99 problems but 8.6 ain't one.

Why do I have to remove VI from SubPanel?

LV 2013, Win7
I have a program where a menu item can open or close a particular window.
That window is large, contains 72 SubPanels, each SubPanel contains a single instance of a reentrant VI (called the BLOCK VI).
I have a LARGE memory leak (about 100 MBytes ) each time the window opens and closes. I'm using the Windows function WORKING SET SIZE to judge memory usage.
In chasing this, I have put a DIAGRAM DISABLE around the entite block diagram of the BLOCK VI. That means it cannot allocate anything in code.
The problem still exists.
I seem to have found the problem, but I don't understand why - it seems to contradict the HELP.
The HELP text for INSERT VI into a SubPanel says this:
I interpret that highlighted part as meaning when my Window VI stops, the VIs will be REMOVED automatically (They have been stopped before).
But that doesn't seem to be the case.
Here is the Memory usage before I discovered the removal angle. I Open and close the window 4 times:
If I REMOVE the VI myself, then here's what it looks like:
--- That's more like I would expect - whatever it uses when open, it gives back when closed.
I have verified it's a real problem - I have a stress test to cycle the open/close operation, and it eventually dies with a MEMORY FULL message.
So, here's the code:
There is a tab control with 12 pages on it. Each page has nothing but six SubPanels on it.
So, I collect those 72 SubPanel references.
For performance reasons, I pick out the page that is showing (set from the last time the user closed it), and launch the blocks for that page first.
I then bring up the window's front panel, and then launch the blocks that are not showing, so that they are ready to go if the user switches tabs.
Here is the LAUNCH BLOCKS code:
I convert the generic ref to a SubPanel Ref, open a CALL and COLLECT reference to the BLOCK VI, and insert the VI, then RUN the BLOCK VI instance.
No errors occur here.
When I CLOSE the window, here's what happens:
The instances of the BLOCK VI have already been told to quit (for this test, they are entirely disabled anyway, so do not run).
I WAIT ON ASYNCH CALL for each one (I don't really need to collect anything, but I need to wait on them quitting. I've been going back and forth between C&C and other methods of doing that.
It's that REMOVE VI part that I DISABLED and ENABLED to produce the mem usage graphs above. Originally I didn't have it, but I tried and it seems to solve the problem.
But why? The help says that I don't need it. After this code, the window VI quits, so they should be removed automatically.
But yet the memory piles up...
QUESTIONS:
1.. Why do I have to REMOVE the VI?
2... Does it matter if I RUN the VI before INSERTING, or INSERT before RUNNING?
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

CoastalMaineBird wrote:
The HELP text for INSERT VI into a SubPanel says this:
QUESTIONS:
1.. Why do I have to REMOVE the VI?
2... Does it matter if I RUN the VI before INSERTING, or INSERT before RUNNING?
I would say that the help is poorly phrased. It's quite easy to demonstrate that the when a VI stops running, the VIs in its subpanels are not removed automatically (see the example). I'm assuming that what was meant here is "until the VI that contains the SP goes idle or out of scope", which is not how most people would interpet "stop". As long as the VI stays in run mode, even if it's not actually running, the FP stays in the SP unless you remove it.
This is the behavior you're seeing and it explains the memory issues. Since you're not removing the FPs, they are apparently staying open, thus making your close ref a no-op, and since you then keep going, they're apparently staying open in the background. This is a guess. I haven't checked it, but it seems to match what you're describing.
And no, I don't think the order of the operations matters, but I would suggest running the VI before inserting, to avoid a case where you have a non-running VI visible.
Try to take over the world!
Attachments:
subpanel example.vit ‏33 KB

How can I call a LabVIEW executable from within another LabVIEW executable?

I have a customer requirement for two LabVIEW executables. Based on their current setup, they need to run executable "A" or "B", both of which are under independent revision control. I have created a third "selection" executable that allows the operator to choose between one of the two, but I am receiving errors when I attempt to call a LabVIEW executable from within a LabVIEW executable using either the "System exec" VI or the "Run Application" VI. If I call a non-LabVIEW executable (such as Windows Explorer) everything works fine.

> I have a customer requirement for two LabVIEW executables. Based on
> their current setup, they need to run executable "A" or "B", both of
> which are under independent revision control. I have created a third
> "selection" executable that allows the operator to choose between one
> of the two, but I am receiving errors when I attempt to call a LabVIEW
> executable from within a LabVIEW executable using either the "System
> exec" VI or the "Run Application" VI. If I call a non-LabVIEW
> executable (such as Windows Explorer) everything works fine.
As with the other poster, I suspect a path problem. You might try the
path out in a shell window, and if it works, copy the complete absolute
path to LV to see if that works. LV is basically passing the comma
nd to
the OS and doesn't even know what is in it, so you should be able to get
it to work.
The other poster commented on subpanels, which is a good suggestion, but
without going to LV7, an EXE can have open more than one VI. You can
use the VI Server and the Run method to fire up another top-level VI.
The decision is whether you want both to be in unique processes.
Greg McKaskle

Any way to show a subvi's frontpanel within its parent with out the cumbersome "subpanel"?

I'm writing an application, where several loops are running in parallel (e. g. read sensor data, receive UDP packets, send UDP packets, wait for input). Except for some configuration data, the loops are completely independent from each other (occasional communication is done via queues). Each of the loops will run indefinitely until told to stop by commands to a queue and is in its own subVI (otherwise the main blockdiagramm just containing the overall state machine would start to grow outside the screen, which is even worse than having to scroll in a text based language). Each of the subVIs also shows some information (status, sensor data, graphs, debugging).
So the big question is: how can I show all these subVIs information in a single window?
Using the "subpanel"-container is pretty much out of question. It adds almost as much clutter to the blockdiagram than the loops would do themselves (with "create vi reference", "insert vi", "run vi", "remove vi"; and that for every parallel subVI) and makes the code harder to maintain. Even worse, Labview is no longer able to tell me if one of the subVIs is currently broken (e. g. because there was a change in a typedef that requires changes in a subVI) until I run the complete program (or open each of the subVIs individually). Getting parameters into and out of the VIs isn't easy either that way (no more simple terminals).
I thought about making the subVIs' appearance titlebar-/menu-/borderless and floating and hardcoding a pixel position for all of them. But I can't really control what resolution the PCs running this program will have. So I fear they will be all over the place with no possibility for the user to move them around. This would also mean the main windows would always have to stick to the top left, which in itself would annoy users.
I remember having this problem already. My solution at this time was to make a copy of every frontpanelobject of the subVIs on the main VI (thereby cluttering the blockdiagram with heaps of unconnected terminals), creating a reference to that object, bundling them all together and writing it in a global variable. Then every subVI would pick out the references it needed and change the value with the value property node. Globals and changing the value per reference both being pretty bad Labview practice, it was still more manageable than dynamic calls to subVIs (which the subpanels comes to, although it shouldn't be needed). What making this approach not very practical this time, is, that some of the subVIs (and what they show) may be developed by other developers. This would mean for every frontpanel object they add/change/remove a reference needs to be added/changed/removed. While the reference list will be it's own cluster typedef, still all other subVIs will have to be updated, too.
Maybe I missed something. But is there really no simple option like "show frontpanel when loaded at this position within parent frontpanel"? Would make things soo much easier and way easier to maintain.

mikeporter wrote:
I'm sorry I'm not aware of any "cumbersome" subpanels - unless of course you don't know what you're doing. There is this wonderful invention called a "subVI" that can be used to organize and simplify your code, or are they too "cumbersome" as well? You should really learn a bit about what you are pontificating over before you start running off at the mouth.
Mike...
I didn't want to step on your toes. No need to get personal.
Subpanels make some additional code necessary that hasn't got to do anything with the actual program. And I AM using subIVs as I wrote in my first post, which is exactly the root of the problem.
Nevertheless I now solved it in a way that comes close to what I wanted. I don't know if some of you meant your suggestions to be understood that way (at least I didn't ). The subVIs will now "insert" themselves (via invoke node) into a subpanel on the main vi, which they are given a reference of at call. This adds minimal aditional code, especially on the main VI which I want to keep as clean as possible. By clustering the panel reference into the parameters the subVIs are already given (not used in the example I attached below), there isn't even a change on the terminals of the subVIs.
I got to check now if this works well with event structures within the subVIs or if it can create the same problems like multiple event structures within a single VI.
So no global variables anymore and no writing values by property node. I don't know if this just wasn't possible in previous Labview versions I had a try at that (I guess it was 8.6 and/or 2009) or I just didn't come up with the idea back then.
And if the text wasn't that helpful, here are two screens:
Parent VI:
SubVI:
Attachments:
main.png ‏2 KB
subvi.png ‏5 KB

Calling a drawLine() from one class to another from an ActionEvent

I have several JPanel objects called and placed on a JFrame. The JFrame has a RadioButton group with radio buttons. If I select a radio button and call a drawLine() method from a JPanel, I receive a "NullPointerException". Is it not possible to call this graphic method from one class to another?
Thanks for any input you can provide.
John

Remember that each panel draws it's own current state. So you need the ActionPerformed to change the state in your target panel.
import java.awt.*;
import java.awt.event.*;
import java.awt.geom.*;
import javax.swing.*;
import javax.swing.event.*;
public class PanelComm extends JPanel {
private SubPanelOne subPanelOne = new SubPanelOne();
private SubPanelTwo subPanelTwo = new SubPanelTwo();
public class SubPanelOne extends JPanel {
    public SubPanelOne () {
      setLayout ( new BorderLayout() );
      setBorder ( BorderFactory.createTitledBorder ( "SubPanel One" ) );
      Reactor     reactor    = new Reactor();
      ButtonGroup group      = new ButtonGroup();
      JPanel      radioPanel = new JPanel(new GridLayout(0, 1));
      JRadioButton buttonOne = new JRadioButton ( "One" );
      buttonOne.addActionListener ( reactor );
      group.add ( buttonOne );
      radioPanel.add ( buttonOne );
      JRadioButton buttonTwo = new JRadioButton ( "Two" );
      buttonTwo.addActionListener ( reactor );
      group.add ( buttonTwo );
      radioPanel.add ( buttonTwo );
      JRadioButton buttonThree = new JRadioButton ( "Three" );
      buttonThree.addActionListener ( reactor );
      group.add ( buttonThree );
      radioPanel.add ( buttonThree );
      add ( radioPanel ,BorderLayout.LINE_START );
    protected void paintComponent ( Graphics _g ) {
      super.paintComponent ( _g );
      Graphics2D g = (Graphics2D)_g;
      g.setRenderingHint ( RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON );
public class SubPanelTwo extends JPanel {
    private JLabel text = new JLabel();
    public SubPanelTwo () {
      setLayout ( new BorderLayout() );
      setBorder ( BorderFactory.createTitledBorder ( "SubPanel Two" ) );
      text.setFont ( new Font ( "Verdana" ,Font.PLAIN ,30 ) );
      text.setHorizontalAlignment ( JLabel.CENTER );
      add ( text ,BorderLayout.CENTER );
    protected void paintComponent ( Graphics _g ) {
      super.paintComponent ( _g );
      Graphics2D g = (Graphics2D)_g;
      g.setRenderingHint ( RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON );
    public void setChoice ( String cmd ) {
      text.setText ( cmd );
public class Reactor implements ActionListener {
    public void actionPerformed ( ActionEvent e ) {
      subPanelTwo.setChoice ( e.getActionCommand() );
public PanelComm () {
    setLayout ( new GridLayout ( 1 ,2 ) );
    add ( subPanelOne );
    add ( subPanelTwo );
// main
public static void main ( String[] args ) {
    JFrame f = new JFrame ( "Panel Communication" );
    f.setDefaultCloseOperation ( JFrame.EXIT_ON_CLOSE );
    f.getContentPane().add ( new PanelComm() ,BorderLayout.CENTER );
    f.setSize ( 320 ,120 );
    f.setVisible ( true );
} // main
}

Subpanel call.

Similar Messages

Maybe you are looking for