Created attachment 7718 [details]
ClassCastException

Created attachment 7719 [details]
fixed NbFrameOperator

As far as I see your fix is not correct.

In case of finding JDesktopIcon, "result" variable should be set to
ifr.getInternalFrame() as it's done in Jemmy.

I'll implement it.

Thanks.

Shura, why ? What is incorrect?

I am using NbFrameOperator at time , when I don't know whether frame I
am looking for is JinternalFrame or JFrame, so for this reason , as I
know we have NbFrameOperator. 

I really don't understand what is incorrect on my fix??? Please let me
know !

In this case we need only prohibit ClassCastException and if somebody
looks for some J(Internal)Frame by title, and this J(Internal)Frame is
iconified it will be nice to return founded frame (JFrame,
JInternalFrame or/and JInternalFrame.JDesktopIcon.

I am sorry, I made some changes to NbFrameOperator as Marian proposed.
I was not able to access Issuezilla to see you started to work on this
bug Shura.
Change it as you considered.

NbFrameOperator can be created for a container - that's how it 
works.

Using you code, you will find JDesktopIcon instance. Thus, you  
will create an operator for component you found - JDesctopPane, 
again - not JInternalFrame. Thus, even if there would be method
unminimizing NbFrameOperator, you wouldn't be able to do so,
because you would receive ClassCastException, probably, when
JDesktopPane would be casted to JInternalFrame.

Your fix is _almost_ correct - you would just add one more line:
if(result instanceof JInternalFrame){
//...
}else if(result instanceof JInternalFrame.JDesktopIcon){
    JInternalFrame.JDesktopIcon ifr = 
(JInternalFrame.JDesktopIcon)result;
    result = ifr.getInternalFrame(); //this one
    params[0] = new Rectangle(ifr.getWidth(), ifr.getHeight());
}

Full fix, however, will be bigger: mizimizing/maximazing methods 
should be implemented as well.

Shura, I used NbFrameOperator only for determine whether my frame is
instanceof JInternalFrame, JFrame or JInternalFrame.JDesktopIcon , and
I used JInternalFrameOpeator for actions with iconified internal
frame. So I used NbFrameOperator as "a general find operator" if I
don't know type of frame.

I agree with additional methods , but in my opinion it will duplicate
methods in JInternalFrameOperator, so again we are doing the same
things on differetn parts of Jelly. 

I wouldn't add minimizing, maximizing or whatever else functionality
into NbFrameOperator. It is not intended to be used to test such
features. JFrameOeprator or JInternalFrameOperator is enough to
provide it. It is easy to convert NbFrameOperator to proper one:

        NbFrameOperator frame = new NbFrameOperator("Explorer");
        JInternalFrameOperator intFrame = new
JInternalFrameOperator(frame);
        intFrame.iconify();

2Jiri. I am not sure myself that those methods should be added. 
However we have to provide some king of shorcut for deminimizing.

Any ideas?

Frame could be deminimized in constructor, what do you think?

I wouldn't do this. Actually, internal frame should not be minimized
when I am going to use NbFrameOperator constructor. If the frame is
minimized, test probably fails in consequent steps. I think it is
allright because it detects unusual state of frame.

So, you mean that issue should not be fixed?

Well, I am not so sure. 

Just think: we do switch tabbed pages, scroll scroll panes, 
activate
windows for components. We even search for invisible TopComponents
lately. Why can't we unminimize internal frames as well?

Generally speaking it could even be a mode in DefaultVisualizer. :)

OK, you are right we do a lot of things like that. So, go ahead and
implement deminimizing it is doable.

Shura:
If we will do deiconify in constructor of NbFrameOperator, than
instance of object for that we construct operator will be changed
during construction from JInternalFrame.JDesktopIcon to
JInternalFrame, it is a bit different as scrolling to or switching tab
!!!!!

Method NbFrameOperator.findJFrameOrJinternalFrame(String, int) returns
container and JInternalFrame.JDesktopIcon is a container, so why we
cann't return it ?

IMHO:
If new JInternalFrameOperator(ContainerOperator, String) returns
JInternalFrameOperator for iconified JInternalFrame - means
JInternalFrame.JDesktopIcon, and if you want deiconify it you use
JInternalFrameOperator.deiconify() too, why we cann't return as new
NbFrameOperator(String) - operator for JInternalFrame.JDesktopIcon ???

Once again I am using it in Window System test library, I don't know
whether it is JFrame or JInternalFrame (rason using NbFrameOperator)
and I don't know it is iconified or not, my resolutions depends on
returned instance.

I hope it's my last comment during issue resolving.
Guys please don't speak, just do it.

Paragraph by paragraph. :)

1. Nothing will be changed during constructor, because constructor 
will receive JInternalFrame instance. Because 
findJFrameOrJinternalFrame(String, int)
will return JInternalFrame.

2. findJFrameOrJinternalFrame(String, int) cannot return a 
Container
simply because NbFrame is designed to represent "frame" idea 
which, depending on mode, could bi either JFrame or 
JInternalFrame - nothing more. Common ancestor of these two is
Container - that's why NbFrame has a constructor with Container
parameter.

You are right about one thing: NbFrame constructor should throw an 
exception when object passed is neither JFrame nor JInternalFrame. 
:)

4. Unminimizing of JInternalFrame could not possible have any bad 
effect on you.

5. I will make right fix. :)
I was waiting for an approval from guys - Jiri gave it. Now I'll 
fix it.

NbFrame now unminimized after finding.

You really did it, I don't believe it ?!

Well, please explain me how can I write next method in Window System
test library :

-------------------------------------------------
    public void deIconify(String iconName) {
        makeLog("Deiconifying window(icon) with name " + iconName);
        
        NbFrameOperator frame = new NbFrameOperator(iconName);
        
        if((frame.getSource() instanceof JInternalFrame) ||
(frame.getSource() i
nstanceof JInternalFrame.JDesktopIcon)){
            JInternalFrameOperator internalOp =
getJInternalFrameOperator(iconNa
me);
            internalOp.deiconify();
        } else {                //SDI
            JFrameOperator frameOp = getJFrameOperator(iconName);
            frameOp.setState(javax.swing.JFrame.NORMAL);
        }
        
        makeLog("Deiconifying window(icon) with name " + iconName + "
- finished
.");
    }
-------------------------------------------------

or

-------------------------------------------------
   public boolean isMinimized(String windowTitle) {
        boolean icon = false;
        
        makeLog("Checking window=["+windowTitle+"] is minimized");
        
        NbFrameOperator frame = new NbFrameOperator(windowTitle);
        
        if(frame.getSource() instanceof JInternalFrame ||
frame.getSource() inst
anceof JInternalFrame.JDesktopIcon){
            JInternalFrameOperator internalOp =
getJInternalFrameOperator(window
Title);
            icon = internalOp.isIcon();
        } else {                //SDI
            makeLog("DOESN'T WORK IN SDI !!!");
        }
        
        makeLog("Checking if window=["+windowTitle+"] minimized
["+icon+"]- fini
shed.");
        return icon;
    }

--------------------------------------------------


because now constructor :
NbFrameOperator frame = new NbFrameOperator(iconName);

deiconify minimized JInternalFrame !!!
Thanks
 

This is intresting. :)

The stuff you do in the isMinimized(String) methods is 
really low-level functionality in terms of NB GUI functional 
testing, so I would use Jemmy directly there.

However, that direct Jemmy usage would look very much the same 
as waitContainer/findJFrameOrJInternalFrame methods from
NbFrame, so why not to open that functionality.

It, of course, would suppose removing deminimization from
findJFrameOrJInternalFrame(String, index) where I put it
simply because the method is private.

Still, most of the test developers have nothing to do
with minimized frame - they only use frames to find
something inside it.

So, having all this in mind, I see two possibilities:

1. 
  - Make both waitContainer and findJFrameOrJInternalFrame public. 
  - Move deminimization into NbFrame constructor.
  - Rename waitContainer to waitJFrameOrJInternalFrame. :)

It will allow you, Marian, to use NbFrame:
((JInternalFrame)NbFrame.waitJFrameOrJInternalFrame(...).getSource()).isIcon()

It won't affect other test developers.


2.
  - implement minimize/deminimize together with maximize/demaximize
    methods in NbFrame.

This way, test developer will only have to call deminimize() method
to turn a frame into the working state.

I'm comfortable with either approach. Jiri, you seemed to be 
objecting
against second. If you still object, I'll implement first.

From given arguments and examples second approach seems to me better.
I didn't want to add methods for minimizing/maximizing to
NbFrameOperator because I thought developer knows if it is JFrame or
JInternalFrame when he is going to minimize/maximize it. So, it seemed
to me as duplication of work.
Now I see Marian's test case where it is reasonable, so no objections
to implement it.

So be it! :)

Marian, in case you have any tescase where this won't work, share with
us! :)

I agree with next solution:
- remove deminimalization from NbFrameOperator - constructor
- implement new methods in NbFrameOperator :
	void minimize()
	void restore()
	void maximize()
	boolean isMinimized()
	boolean isMaximized()

method restore() is wrapper for deminimize and demaximize depends on
frame status.

Fixed as proposed.

New methods: isMinimum(), isMaximum(), minimize(), maximize(),
normalize().

NOTE: maximize() and isMaximum() do not completely work for JFrame,
because there is no API to define if JFrame is maximazed or to
maximize it.

maximize() simply deiconifies JFrame if it was iconified.
isMaximum() returns true whenever frame is not iconified.

verified