Issue 96113 - sw: ambiguous && ||
Summary: sw: ambiguous && ||
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: DEV300m35
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: Oliver Specht
QA Contact: issues@sw
URL:
Keywords:
Depends on:
Blocks: 96084
  Show dependency tree
 
Reported: 2008-11-11 16:58 UTC by caolanm
Modified: 2013-08-07 14:43 UTC (History)
1 user (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
version 1, keeps current behaviour (1.14 KB, patch)
2008-11-11 16:59 UTC, caolanm 		no flags Details | Diff
changes current behaviour, but might be what was intended (1.15 KB, patch)
2008-11-11 16:59 UTC, caolanm 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2008-11-11 16:58:36 UTC 
in 
sw/source/ui/utlui/navipi.cxx
we have...

if(aTmpParentSize.Width() < aMinSize.Width() ||
 aTmpParentSize.Height() < aMinSize.Height() &&
     ((SfxDockingWindow*)pParent)->GetFloatingWindow() &&
         !((SfxDockingWindow*)pParent)->GetFloatingWindow()->IsRollUp())

which means (after expanding operator precedence)

if (
 aTmpParentSize.Width() < aMinSize.Width() ||
 (
  aTmpParentSize.Height() < aMinSize.Height() &&
  ((SfxDockingWindow*)pParent)->GetFloatingWindow() &&
  !((SfxDockingWindow*)pParent)->GetFloatingWindow()->IsRollUp()
 )
)

is that really what we want ?, if so then patch A makes that explicit

or do we really want

if (
    (
     aTmpParentSize.Width() < aMinSize.Width() ||
     aTmpParentSize.Height() < aMinSize.Height() 
    ) &&
    ((SfxDockingWindow*)pParent)->GetFloatingWindow() &&
    !((SfxDockingWindow*)pParent)->GetFloatingWindow()->IsRollUp()
   )

which is not what we do now, but might be our intention, in which case
attachment 2 [details] makes that explicit
Comment 1 caolanm 2008-11-11 16:59:09 UTC 
Created attachment 57899 [details]
version 1, keeps current behaviour
Comment 2 caolanm 2008-11-11 16:59:47 UTC 
Created attachment 57900 [details]
changes current behaviour, but might be what was intended
Comment 3 andreas.martens 2009-01-19 08:12:57 UTC 
Fixed in CWS sw31bf02.
Comment 4 andreas.martens 2009-01-23 13:31:07 UTC 
Ready for QA ;-)
Comment 5 Oliver Specht 2009-01-26 09:03:48 UTC 
verified in cws sw31bf02
Comment 6 caolanm 2009-03-23 16:22:15 UTC 
closed, integrated