Hiding Jframe from start Menu

[zelao.itu]

Hi, in my application, when the usar click in a button it's call
another Jframe.

class First {
JButton a;
When a clicked then
new Second()
}

class Second extends JFrame { }

but when class Seconds is called it's create a new Item in start menu.
So, how could I hide the old item (item of the first class) from
start menu ?

if it isn't possible, What can I do to solve my problem ?

Thanks

 

[Andrew Thompson]

Hi, in my application, when the usar click in a button it's call
another Jframe.

Why? What's in the second frame?
Why not put the contents of the second
frame into a CardLayout in the first frame?
Is it necessary for the contents of the first frame to
be *visible* while the second is open?
It is neccessary to be able to *click* *on* GUI elements
in the first frame, while the second is showing?

if it isn't possible, What can I do to solve my problem ?

I don't know what your prblem is yet, and I suspect,
netither do you. You might be using an entirely
inappropraite UI component for the second set of controls.

Perhaps if you can desribe better what the first frame
is, and what the the second frame is, we can suggest
better alternatives (like JDialog, JInternalFrames(?), a
JSplitPane or CardLayout..).

Andrew T.

 

[Philipp]

Why? What's in the second frame?
Why not put the contents of the second
frame into a CardLayout in the first frame?
Is it necessary for the contents of the first frame to
be *visible* while the second is open?
It is neccessary to be able to *click* *on* GUI elements
in the first frame, while the second is showing?


I don't know what your prblem is yet, and I suspect,
netither do you. You might be using an entirely
inappropraite UI component for the second set of controls.

Perhaps if you can desribe better what the first frame
is, and what the the second frame is, we can suggest
better alternatives (like JDialog, JInternalFrames(?), a
JSplitPane or CardLayout..).

If I understood the question right, I would also be interested if there
exists a solution to this (NOT a workaround as you suggest):

How can one (in java) open a "window" in a win32 system without it
showing in the taskbar?

Your two first workarounds do not work because:
- JDialog:
- if modal = true, needs a parent frame an can only have exclusive-focus.
- if modal = false (and parent=null), a window of your app may
disappear behind another processes window and cannot be brought to front
anymore.

- JInternalFrame: you always have to have that JDesktopPane around it.

Thanks for answers.
Phil

 

[zelao.itu]

Philipp are absolute correct. It's exactly my problem. I don't want
JDialog or JInternaFrame.
I'm doing a software to control products, sells, buys, etc.

 

[Andrew Thompson]

The OP never answered this simple question.
If the OP does not wish to discuss it, I am not
that interested in continuing the thread (after all -
this is not a help-desk).

Your two first workarounds do not work because:
- JDialog:
- if modal = true, needs a parent frame an can only have exclusive-focus.
- if modal = false (and parent=null), a window of your app may
disappear behind another processes window and cannot be brought to front
anymore.

Of course it can - try reading the documentation.
// if not dealing with a dialog
// Window.setVisible(true)
Window.toFront()

Andrew T.

 

[Philipp]

The OP never answered this simple question.
If the OP does not wish to discuss it, I am not
that interested in continuing the thread (after all -
this is not a help-desk).

Thanks for taking of your precious time to answer.
Would it have been more appropriate to start a new thread when
expressing my personal interest in the OPs question?

Of course it can - try reading the documentation.
// if not dealing with a dialog
// Window.setVisible(true)
Window.toFront()

Note that in this case (not a dialog) the window has an icon in the
taskbar (which is the whole point we want to avoid).

You can create JDialog's, non-modal, parent = null, and then keep track
of each of them. Then when the app gets focus (in the OS I mean),
iterate through all these windows and call .toFront() on each of them
(and at last call toFront() on the window which made the app come to front).

IMHO this method is ugly. It works on win32, I tried it. It has some
strange side-effects on Solaris (can't recall exactly what though).

My question is more, is there a built-in Java way to get this behavior?

Thanks Phil




I did something like you say, So the solution you advise, is to have a
class extending

 

[zelao.itu]

Ok Sorry. Let's try again.

My First Frame has a table where I list products and a button called
"Add", when Add Clicked, I Open a New Frame (it's can not be Internal
but it's can be modal). So this new Frame has fields to register news
products, and a Button OK to save the new Product in a DataBase.

I'm using JFrame, so the second frame create a icon on taskbar, and I
don't want a new Icon, I want just a single icon, and when user click
on this icon, it's call the previous JFrame, in this case the Register
Frame.

Thank's a lot

 

[Ian Wilson]

Ok Sorry. Let's try again.

My First Frame has a table where I list products and a button called
"Add", when Add Clicked, I Open a New Frame (it's can not be Internal
but it's can be modal). So this new Frame has fields to register
news products, and a Button OK to save the new Product in a DataBase.


I'm using JFrame, so the second frame create a icon on taskbar, and I
don't want a new Icon, I want just a single icon,

A dialog has this property. There is an icon on the Windows taskbar for
the JFrame but not for the JDialog.

and when user click on this icon, it's call the previous JFrame, in
this case the Register Frame.

I'd make it a non-modal dialog. I guess you'll need to catch some event
to force focus to the JFrame and raise it over the JDialog. :-(

 

[zelao.itu]

I solve my problem replacing all extends JFrame to extends JDialog.

Thanks!!!

 

[Andrew Thompson]

I solve my problem replacing all extends JFrame to extends JDialog.

(groans) And gee. I only mentioned that in the last
paragraph of the very *first* reply..

Andrew T.