#Object names & Unlock
7 messages in this thread
Jerrell,
I've been trying to access a textfield that is only different in its name.
It contains a space in the field name. When I try to "Click on …." this
textfield it won't and the screen flickers. I've tried it through the id
number but still the same. Maybe something for you to look into.
Why is it that the "unlock display" command set doesn't accept variables
for the keywords like "wipe", "down" etc. I tried many different ways to
compile the unlock display command line but it wouldn't use the variables
instead of the proper text. I finally had to compile the complete line and
then "interpret" it. Just wondered why it wouldn't accept the variables.
Charles Collinson – Co-ordinated Computer Integration
Thirsk – North Yorkshire – UK
Charles,
I did find a minor problem with the "Click on" command. It doesn't abort the
script and display an error if the object reference if malformed. However, if
the object reference is accurate, the command works fine. This is probably not
the problem because you tried specifying the object in different ways. There is
another possibility. The "click" command simulates a mouse click at the exact
center of the object. If there is another object on top of the object at this
point, the specified object will not be activated.
The "unlock display" command is accepting containers for the transition name.
Is it possible that you forgot the <with> keyword which tells Helm a transition
name is coming. I just tried this script and it works:
on SelectUp
begin
put "scroll" into mytransition
lock display
unlock display with mytransition right
end
However, there is currently no way to specify the direction of the transition
at run time. It has to be an explicit part of the command. The next upgrade
will probably include a way of dynamically selecting the transition direction.
For now, you can get around the limitation like this:
on SelectUp
begin
put textfield "Transition" into mytransition
put textfield "Direction" into mydirection
lock display
if mydirection is "right" unlock display with mytransition right
else if mydirection is "left" unlock display with mytransition left
else if mydirection is "down" unlock display with mytransition down
else unlock display with mytransition up
end
It is a little awkward but I think it will take care of your problem.
Jerrell Nickerson
Eagle Tree Software
Jerrell,
Well there isn't anything over the textfield when I "click on" it. I'll
check again but there isn't. If there is it doesn't show when I say edit
it and if there was anything there it would have to be over other
textfields that are named by a single word and/or id number and work fine.
It does seem strange – I'll give it another look tonight.
As to the unlock display, I was using a long ways around approach and not
as you did it. I was compiling most of the line e.g. X = " "&textfield
"Effect". I did this with all the variables and then added them onto the
end of the line "Unlock display with". I was placing spaces in the line,
why I'm not sure (good old me), probably something to do with the many
objects and there respected requirements with regard syntax getting me
confused. I included effect, speed and direction in the line no matter
what effect I was using. Well it didn't work. What I finally did was as
above but included the "Unlock display" in my final variable and then
"interpret" the variable – this worked fine whatever the effect, speed or
direction. It is, I think, better than the script you wrote, unless I loss
time with the interpret command. Something I can't readily tell doing
40Mhz.
My unlock display script:
X = Textfield id 134 //Effect e.g. Scroll
C = Textfield id 137 //Direction e.g. Up
V = Textfield id 152 //Speed e.g. 7
EF = "unlock display with"&" "&X&" "&C&" "&"Speed "&V&" "&"Area
yuyu.108,53,529,222"
interpret EF
While we are talking id numbers here. It mentions in the manual about
group ids. Is this actually in Helm and if so where do I find a group id,
or group information for that matter.
Thanks for your time and I'll go figure this "Click on" prob.
P.S. What I would like to see in Helm and further to the "Book", "Form"
and "Page" menu requesters where it shows you what type and quantity of
objects are on said, is the same for a layer. I use many layers and
looking to see if I have the right amount of objects etc on a form is not
enough as I may have 100 and I'm not one for counting them all just to
check 10 objects on one layer. I'm only looking of someway of counting
them. Don't tell me "number of objects of layer "ABC"" works does it?
Charles Collinson – Co-ordinated Computer Integration
Thirsk – North Yorkshire – UK
Charles,
I haven't been able to repeat the problem with not being able to click on a
textfield. I'll keep looking. I don't think the fact that the name has multiple
words is a problem. I know this is a long shot: Is "Ignore Input" selected?
Speed is the only disadvantage to your script for unlocking the display. It
takes a little time to concatenate the string and then the <Interpret> command
must run it through the compiler before it is executed. However, it is a very
small amount of time so it is a good solution. This version is a couple of
lines longer but it will do the same thing without the "Interpret" command.
X = Textfield id 134 //Effect e.g. Scroll
C = Textfield id 137 //Direction e.g. Up
V = Textfield id 152 //Speed e.g. 7
if C is "right" unlock display with X right speed V area 108,53,529,222
else if C is "left" unlock display with X left speed V area 108,53,529,222
else if C is "down" unlock display with X down speed V area 108,53,529,222
else unlock display with X up speed V area 108,53,529,222
The <groupid> property of an object is always the id number of one of the
objects in the group. You can set or get it like any other property. If the
object is not in a group, the <groupid> property is set to $ffff.
No, there is no way to get the number of objects in a layer or the depth of
each object within a layer. I'll give it some thought for a future version.
Jerrell Nickerson
Eagle Tree Software
Jerrell,
I didn't get time to play with the "Click on…" prob. I will though. In
the book I'm working on, which is based on your Bookcase book, I find the
book is some 200K which I find difficult to believe. This could be
pointing to some problem or other that relates to the "click on.." prob.
Ah! The disadvantages of a 030 40Mhz chip eh. Which would be the faster my
intrepret command in the object script or your script in a book or form
function?
Failing the number of objects on a layer, what about a detailed listing of
all objects, i.e. location (form/page/layer), X,Y location,
shared/nonshared, book byte usage and anything else you can think of (and
or Helm holds info on) to aid authors track down bits n pieces. I ask this
as it is quite easy to have massive books in Helm and get totally lost
looking for stuff, especially when you've forgotten where it was etc. This
needs only be a standard printed report for all I care as long as I can
access it for design purposes.
Another idea that would greatly help. It can be a bind sometimes to
re-position the depth of objects using the menu selection. I take it this
is the only way. What about a depth slider where I can select the object
with the edit tool and then use a slider to actually move the objects
depth in realtime as it were. I could place it in seconds. Just an idea.
Charles Collinson – Co-ordinated Computer Integration
Thirsk – North Yorkshire – UK
Charles,
I fixed the problem with the <click on> command. It was strange. If the script
contained a sequence with a <popup> command followed by an <unlock display>
command followed by a <click> command, Helm would ignore the click command.
Thanks for mailing the script to me I could figure it out.
Helm 2 will be able to print out all of the properties of one or more objects.
It is the same list of properties and values that will appear in the new
property browser.
That is and interesting idea about the slider for changing the depth of
objects. Maybe I can work it into the property browser.
Jerrell Nickerson
Eagle Tree Software
Jerrell,
Well that WAS an obscure problem with the <click on> command. At least I
got round it. Quite how and why I don't know :). I've just been looking at
the <popup> command syntax and was wondering whether there was a case for
adding a border keyword in there. I'm not totally sure I really need one
as I was thinking more on the lines of a scolling textfield effect for the
popup command on a <selectdown> event, I gleemed this from another program
I saw with the effect. No matter, just thinking aloud.
I did however come over one point while I was looking through your guide
files. Is it possible to alter the colours of Helm's amigaguide files that
are placed on the Helm screen. I don't get the nice (standard) main grey
background colour and black text, borders.
I recall you mentioned the ability of this new property browser, but will
it contain info like byte size so we can assess a value to the object more
readily? Surely Helm has this info at hand in a book and it would, I
think, certainly help track down major usage of book sizes. Again I'm
looking at this from a misunderstanding, as Helm uses memory very
effectively so this idea would be pointless in some ways.
I don't like messing with the depth system if I can help it, as it is a
real hassle but it has to be done on most occasions when re-developing
stuff. A fast an' easy way would be a big benefit.
I'll have to stop coming here. All this talk of Helm 2 – as if I'm not
already eagerly awaiting it as is :).
Charles Collinson – Co-ordinated Computer Integration
Thirsk – North Yorkshire – UK