v14 selection bug?
Jeremy Roussak (4/9/14 11:28PM)
Keisuke Miyako (4/9/14 11:46PM)
Keisuke Miyako (4/10/14 12:47AM)
Jeremy Roussak (4/10/14 8:21AM)
Jeremy Roussak (4/25/14 10:50AM)
Jeremy Roussak (4/9/14 11:28 PM)
Miyako,
Here's a test database I just created in 14.1 (157407):
https://dl.dropboxusercontent.com/u/2477609/foo.4dbase.zip. Unzip it,
open project form bar and run it. Type "abcde" into the variable
object and select "bcd". Then deactivate the window, either by
activating a different 4D window or by switching out of 4D altogether.
Then go back to that window: the selection will have disappeared and
the insertion point will be before the "b".
Checking the property "selection always visible" does indeed cure the
problem, but it shouldn't be necessary, should it?
I've filed a bug report (ACI0087463).
Jeremy
Jeremy Roussak
jbr@...
On 9 Apr 2014, at 22:46, Keisuke Miyako <Keisuke.Miyako@... wrote:
color><param>00000,0000,DDEE/param>HHello,
it does sound like a regression, but I can?=80ôt seem to reproduce
it on
Mac
OS, 14.1 (157407)
meanwhile, there is a property ?=80úselection always visible?=80ù
which well
keep
the highlight (grayed out) even if the application loses focus.
miyako
/color>
Keisuke Miyako (4/9/14 11:46 PM)
Hello,
it does sound like a regression, but I can?=A2?=82¨=E2Ñ¢t seem
to reproduce it on
Mac
OS, 14.1 (157407)
meanwhile, there is a property ?=A2?=82¨=C5ìselection always
visible?=A2?=82¨=C2ù which
well keep
the highlight (grayed out) even if the application loses focus.
miyako
On 2014/04/09 23:45, "Jeremy Roussak" <jbr@... wrote:
color><param>00000,0000,DDEE/param>II don't recall this happening in
v13. It seems like a bug to me. Any
comments?
/color>
Keisuke Miyako (4/10/14 12:47 AM)
OK, I understand now and reproduce the problem.
because the 4D language effectively treats ?=A2?=82¨=C5ìinsertion
point
(caret)?=A2?=82¨=C2ù and
highlight as the same thing,
I made the mistake of only looking at the caret position.
you say ?=A2?=82¨=C5ìit shouldn?=A2?=82¨=E2Ñ¢t be
necessary?=A2?=82¨=C2ù, but I think the previous
(~v13)
behaviour
where the highlight is cleared while the application does not have
focus,
and recovers it once it regains focus,
is at odds with other applications.
On 2014/04/10 8:28, "Jeremy Roussak" <jbr@... wrote:
color><param>00000,0000,DDEE/param>CChecking the property "selection
always visible" does indeed cure the
problem, but it shouldn't be necessary, should it?
/color>
Jeremy Roussak (4/10/14 8:21 AM)
I have to confess to not having noticed that <<v13 cleared the
highlight when the window was deactivated. That's obviously the wrong
thing to do; and I agree entirely that the current behaviour when
"selection always visible" is checked is correct and in conformity
with other apps. I'll gradually go through my forms, checking that
option - but why is it even an option, rather than default behaviour?
However, I think we can agree that current behaviour without that
option checked is flawed. Even if 4D behaves badly cosmetically by
hiding the highlight, it shouldn't lose it. I don't imagine it's going
to be difficult to fix, happily.
Jeremy
Jeremy Roussak
jbr@...
On 9 Apr 2014, at 23:47, Keisuke Miyako <Keisuke.Miyako@... wrote:
color><param>00000,0000,DDEE/param>OOK, I understand now and reproduce
the problem.
because the 4D language effectively treats ?=80úinsertion point
(caret)?=80ù
and
highlight as the same thing,
I made the mistake of only looking at the caret position.
you say ?=80úit shouldn?=80ôt be necessary?=80ù, but I think
the previous (~v13)
behaviour
where the highlight is cleared while the application does not have
focus,
and recovers it once it regains focus,
is at odds with other applications.
On 2014/04/10 8:28, "Jeremy Roussak" <jbr@... wrote:
/color><color><param>8826F,0000,8219/param>CChecking the property
"selection always visible" does indeed cure the
problem, but it shouldn't be necessary, should it?
/color>
Jeremy Roussak (4/25/14 10:50 AM)
A quick follow-up to this. If "selection always visible" is checked
for a field, it seems to mean exactly what is says: the selection is
*always* visible, even when the object doesn't have focus. I don't
think this is accepted behaviour in any circumstances. It's horribly
ugly.
Jeremy
Jeremy Roussak
jbr@...
On 10 Apr 2014, at 08:21, Jeremy Roussak <jbr@... wrote:
color><param>00000,0000,DDEE/param>II have to confess to not having
noticed that <<v13 cleared the highlight when the window was
deactivated. That's obviously the wrong thing to do; and I agree
entirely that the current behaviour when "selection always visible" is
checked is correct and in conformity with other apps. I'll gradually
go through my forms, checking that option - but why is it even an
option, rather than default behaviour?
However, I think we can agree that current behaviour without that
option checked is flawed. Even if 4D behaves badly cosmetically by
hiding the highlight, it shouldn't lose it. I don't imagine it's going
to be difficult to fix, happily.
Jeremy
Jeremy Roussak
jbr@...
On 9 Apr 2014, at 23:47, Keisuke Miyako <Keisuke.Miyako@... wrote:
/color><color><param>8826F,0000,8219/param>OOK, I understand now and
reproduce the problem.
because the 4D language effectively treats ?=80úinsertion point
(caret)?=80ù
and
highlight as the same thing,
I made the mistake of only looking at the caret position.
you say ?=80úit shouldn?=80ôt be necessary?=80ù, but I think
the previous (~v13)
behaviour
where the highlight is cleared while the application does not have
focus,
and recovers it once it regains focus,
is at odds with other applications.
On 2014/04/10 8:28, "Jeremy Roussak" <jbr@... wrote:
/color><color><param>FFC79,0365,0771/param>CChecking the property
"selection always visible" does indeed cure the
problem, but it shouldn't be necessary, should it?
/color>
Reply to this message
Summary created 4/25/14 at 6:57PM by Intellex Corporation
Comments welcome at: feedback@intellexcorp.com