Invisible insertion point in field

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Invisible insertion point in field

David Wilkinson-4
I imagine there is an obvious answer to this but I cannot figure it
out.

I have uploaded an experimental table field stack to my user space
(user227), which uses work by and ideas from Chipp Walters, Sarah
Reichelt and Scott Rossi.  It has an edit field that sits on top
of a  worksheet/grid field. The problem is that although you can
enter text in the edit field, the insertion point is invisible. Does
anyone know why this might be?  One possible clue is that in order to
drag the field with the left mouse button, the field has to be locked
when the mouse enters its border zone and the insertion point does
not show in lockedtext fields - but then you can't enter text in such
field either.

As a side question, is there any reason why Rev should set the
vscroll of this field to 4?  I cannot recall any code that scrolls it
directly and notionally the textheight and textsize are the same as
the underlying field.  I suspect this might be tied to the vertical
offset from which text entered into fields, with hgrid enabled, seems
to suffer.

TIA

David Wilkinson

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Invisible insertion point in field

J. Landman Gay
David Wilkinson wrote:

> The problem is that although you can
> enter text in the edit field, the insertion point is invisible. Does
> anyone know why this might be?

Does the field have both the traversalOn property and the autoHilite
property set to true?

To lock/unlock a field you need to set three field properties: locktext,
autohilite, traversalOn. The last two should be set to the opposite of
the first one.


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

RE: Invisible insertion point in field

Lynch, Jonathan
In reply to this post by David Wilkinson-4
I also find that sometimes fields just become corrupted and have to be
replaced (just happened to me). This basically means creating a new
field, setting it's name, script, and other properties to the same as
the old field - and getting rid of the old field.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of J. Landman
Gay
Sent: Wednesday, July 20, 2005 12:21 PM
To: How to use Revolution
Subject: Re: Invisible insertion point in field

David Wilkinson wrote:

> The problem is that although you can
> enter text in the edit field, the insertion point is invisible. Does
> anyone know why this might be?

Does the field have both the traversalOn property and the autoHilite
property set to true?

To lock/unlock a field you need to set three field properties: locktext,

autohilite, traversalOn. The last two should be set to the opposite of
the first one.


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Invisible insertion point in field

Richard Gaskin
Lynch, Jonathan wrote:
> I also find that sometimes fields just become corrupted and have to be
> replaced (just happened to me). This basically means creating a new
> field, setting it's name, script, and other properties to the same as
> the old field - and getting rid of the old field.

I've seen rare cases of images becoming corrupted, but never a field.

Have you found a recipe for this?
Sent your corrupted object to RunRev?

--
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  [hidden email]       http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Invisible insertion point in field

J. Landman Gay
In reply to this post by Lynch, Jonathan
Lynch, Jonathan wrote:
 > I also find that sometimes fields just become corrupted and have to be
 > replaced (just happened to me). This basically means creating a new
 > field, setting it's name, script, and other properties to the same as
 > the old field - and getting rid of the old field.

I've never seen this happen. Do you have a recipe, or any idea what
might cause it? Maybe it isn't really corruption?

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

RE: Invisible insertion point in field

Lynch, Jonathan
In reply to this post by David Wilkinson-4
Well - I just had a field do the strangest thing...

I have a button that inserts a link that opens up whatever document you
link it to.

After it inserts that link, which is a wing-dings character, it then
resets the font information in the selection just after the character to
be what it was before the document link was inserted.

For some reason, on this field, it kept using the wingdings font after I
inserted the document link - I have no idea why. In all other fields, it
worked like it was supposed to. When I compared properties in the
property inspector for this field, and for a working field, I could not
find any differences.

Recreating the field took care of the problem, however.

I have also had a field keep my cursor invisible, and recreating that
field got rid of that problem as well.

I cannot be sure there wasn't some property setting that I was not
getting right in either case - just that I could not find such a
setting.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of J. Landman
Gay
Sent: Wednesday, July 20, 2005 12:51 PM
Cc: How to use Revolution
Subject: Re: Invisible insertion point in field

Lynch, Jonathan wrote:
 > I also find that sometimes fields just become corrupted and have to
be
 > replaced (just happened to me). This basically means creating a new
 > field, setting it's name, script, and other properties to the same as
 > the old field - and getting rid of the old field.

I've never seen this happen. Do you have a recipe, or any idea what
might cause it? Maybe it isn't really corruption?

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Invisible insertion point in field

Stephen Barncard
In reply to this post by Richard Gaskin
>
>I've seen rare cases of images becoming corrupted, but never a field.
>  Richard Gaskin

This has happened to me several times -- usually the problem is the
insertion point missing or I am unable to enter or change text in the
field.

I've been experimenting with some "object creation from text"
routines, where I get all the properties of an object, arrange as
tabbed/return text (with adjustments for the imbedded returns in some
of the data), store the description info in a custom property, then
recreate the object anew with the CREATE command, turn the property
into an array, and finally apply the array to the new object. I have
not extended this into groups yet, but seems not to hard to do.

I guess that could be fashioned into a 'biofilter' for errant objects.

I wonder what a corrupted component would do to such a grinder? I
guess I'd trap the errors and find a way to filter the garbage. A
utility for a rainy day.

This is very similar to the way object properties were handled in the
great product "Windowscript" (another legendary Heizer product (I
bought all their goodies).

sqb

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Invisible insertion point in field

Charles Hartman
In reply to this post by Lynch, Jonathan
This _sounds_ like the same problem I was posting about a week or two  
ago. Test for similarity of bug: in msg box do "put the htmltext of  
fld '<fieldname>'" and look in the output for a bous "<font" tag  
added by Rev; it would hard-wire the current default (owner's) font.  
Further test: is this in a substack? If yes to both, that's the bug I  
posted. (Solution found later: pre-hard-wire the default font in the  
substack.)

Charles Hartman


On Jul 20, 2005, at 1:05 PM, Lynch, Jonathan wrote:

> After it inserts that link, which is a wing-dings character, it then
> resets the font information in the selection just after the  
> character to
> be what it was before the document link was inserted.
>
> For some reason, on this field, it kept using the wingdings font  
> after I
> inserted the document link - I have no idea why. In all other  
> fields, it
> worked like it was supposed to. When I compared properties in the
> property inspector for this field, and for a working field, I could  
> not
> find any differences.
>

Charles Hartman
Professor of English, Poet in Residence
Connecticut College
[hidden email]
*the Scandroid* is at cherry.conncoll.edu/cohar/Programs.htm


_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Invisible insertion point in field

David Wilkinson-4
In reply to this post by David Wilkinson-4
On Wednesday 20 July 2005 6:00 pm, Jacqueline Landman Gay wrote:

> To lock/unlock a field you need to set three field properties:
> locktext, autohilite, traversalOn. The last two should be set to
> the opposite of the first one.

Unfortunately they are opposite

As a test, as a result of Jonathon's post, I created a new stack,
dragged a table field onto it along with a ordinary one.  I grouped
them, edited the group and dragged another single field into the
group.  All was as expected - insertion point etc.

I also tried edting the group of the uploaded teststack and dragging
a new field into the group.  This new field  had no insertion
point.

That suggests some sort of inheritance issue, but I could not see any
obvious differences between the properties in the group, card or
stack of the two examples.  If the edit field is copied from the
group and pasted onto the card, the insertion point then becomes
visible.

BTW in order to get left mouse drag of the field, I only needed to
set the locktext to true - those associated props do not appear to
change when this is done.

Thanks for your rapid response.  The problem isn't critical but gives
this table component an additional element of flakiness it could do
without!

David
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Invisible insertion point in field

Sarah Reichelt
In reply to this post by David Wilkinson-4
> I have uploaded an experimental table field stack to my user space
> (user227), which uses work by and ideas from Chipp Walters, Sarah
> Reichelt and Scott Rossi.  It has an edit field that sits on top
> of a  worksheet/grid field. The problem is that although you can
> enter text in the edit field, the insertion point is invisible. Does
> anyone know why this might be?
The usual cause for this is that the field is overlapped by part of a  
group. For some reason this makes the insertion point disappear. Try  
moving your edit field or bringing it to the front and see if that  
fixes it.
>
> As a side question, is there any reason why Rev should set the
> vscroll of this field to 4?
Would that be because of the margins? I haven't tested this, but try  
setting the margins to 0 and then checking the vscroll.

HTH,
Sarah

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Invisible insertion point in field

Chipp Walters
In reply to this post by David Wilkinson-4
David,

I've seen this happen if a fld is 'overlapped' by any part of a group.

-Chipp
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution