SKILL ProgressBar symbol vs. variable

Guest
Hi
I create progress bar box with hiDisplayProgressBox( ?name 'pb ...) <-
pb is any symbol correct?
I can set progress as it proceed with hiSetProgress( pb ++ii ) <- pb
should point to my progressBar?
But here pb is variable not a symbol. If I put 'pb (symbol) SKILL
parser reports an error.
If just pb (variable) everything fine, BUT.
After procedure is done, I get error report: *Error* unbound variable
- pb.

I placed pb as local variable, inside prog statement - another error
message appears on hiDisplayProgressBox( ?name 'pb ...) - Syntax
error...pb - nil

What and where can be wrong?

Thank you
-Edis
 
edis105136@hotmail.com wrote, on 05/28/09 17:55:
Hi
I create progress bar box with hiDisplayProgressBox( ?name 'pb ...) <-
pb is any symbol correct?
I can set progress as it proceed with hiSetProgress( pb ++ii ) <- pb
should point to my progressBar?
But here pb is variable not a symbol. If I put 'pb (symbol) SKILL
parser reports an error.
If just pb (variable) everything fine, BUT.
After procedure is done, I get error report: *Error* unbound variable
- pb.

I placed pb as local variable, inside prog statement - another error
message appears on hiDisplayProgressBox( ?name 'pb ...) - Syntax
error...pb - nil

What and where can be wrong?

Thank you
-Edis
Click to expand...
Whenever you create a top level user interface item (e.g. a form, a menu, a
dialog box, or a progress box) you need to give it a name. This name is the name
of a variable in which to store the structures for the user interface item.

The variable must be global (in general this is true, there are some exceptions
if you know what you're doing with a form - for example you display a blocking
form in the same scope that it's created). The reason being is that when the
interaction with the user interface item occurs, a SKILL expression is generated
to do the action - and this is recorded in the CDS.log file. The user interface
item knows the name of the variable (which is why you pass the variable name as
a symbol - it then knows the name of the variable it is stored in). If the
variable was a local variable at the time you created the item, it may not be in
scope by the time you interact with the form/progress bar etc.

So in this case, if you create the progress bar in a function with pb as a local
variable, and then try to reference the handle for it in a different scope, it
may not be bound.

The best thing is therefore to make it always global.

Note that user interface items which are not top level (e.g. menu items, form
fields etc) do not need to be stored in global variables (or even in variables
at all) because they are accessed via the top level UI structure.

Sorry if I got my terminology mangled in places - I wrote this in a rush and
didn't take enough care to ensure everything was clean and consistent...

Best Regards,

Andrew.
 
On May 28, 8:45 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
edis105...@hotmail.com wrote, on 05/28/09 17:55:



Hi
I create progress bar box with hiDisplayProgressBox( ?name 'pb ...) <-
pb is any symbol correct?
I can set progress as it proceed with hiSetProgress( pb ++ii ) <- pb
should point to my progressBar?
But here pb is variable not a symbol. If I put 'pb (symbol) SKILL
parser reports an error.
If just pb (variable) everything fine, BUT.
After procedure is done, I get error report: *Error* unbound variable
- pb.

I placed pb as local variable, inside prog statement - another error
message appears on hiDisplayProgressBox( ?name 'pb ...) - Syntax
error...pb - nil

What and where can be wrong?

Thank you
-Edis

Whenever you create a top level user interface item (e.g. a form, a menu, a
dialog box, or a progress box) you need to give it a name. This name is the name
of a variable in which to store the structures for the user interface item.

The variable must be global (in general this is true, there are some exceptions
if you know what you're doing with a form - for example you display a blocking
form in the same scope that it's created). The reason being is that when the
interaction with the user interface item occurs, a SKILL expression is generated
to do the action - and this is recorded in the CDS.log file. The user interface
item knows the name of the variable (which is why you pass the variable name as
a symbol - it then knows the name of the variable it is stored in). If the
variable was a local variable at the time you created the item, it may not be in
scope by the time you interact with the form/progress bar etc.

So in this case, if you create the progress bar in a function with pb as a local
variable, and then try to reference the handle for it in a different scope, it
may not be bound.

The best thing is therefore to make it always global.

Note that user interface items which are not top level (e.g. menu items, form
fields etc) do not need to be stored in global variables (or even in variables
at all) because they are accessed via the top level UI structure.

Sorry if I got my terminology mangled in places - I wrote this in a rush and
didn't take enough care to ensure everything was clean and consistent...

Best Regards,

Andrew.
Click to expand...
Thank you, Andrew
Here are 2 exmples. Please, advise which one is correct.

procedure( exmple1(@optional (var1 500000))
prog( ( pbLocal)
; .
hiDisplayProgressBox(
?name 'pbGlobal ; <- creates global variable
?banner "Collecting cells"
?text sprintf( nil "Please, wait..." )
?totalSteps var1
?autoClose 't
);progress
for( ii 0 var1
hiSetProgress( pbGlobal ++ii ) ; access to global
);for
printf("*Ex1* pbLocal = %L pbGlobal = %L\n" pbLocal pbGlobal)
when(boundp('pbGlobal) pbGlobal='unbound)
);prog
printf("*Ex1* pbGlobal = %L\n" pbGlobal)
t
);proc
printf("exmple1()\n")
;
procedure( exmple2(@optional (var1 500000))
prog( ( pbLocal)
; .
pbLocal=hiDisplayProgressBox(
?name 'pbGlobal ; <- creates global variable
?banner "Collecting cells"
?text sprintf( nil "Please, wait..." )
?totalSteps var1
?autoClose 't
);progress
for( ii 0 var1
hiSetProgress( pbGlobal ++ii ) ; access to global
);for
printf("*Ex2* pbLocal = %L pbGlobal = %L\n" pbLocal pbGlobal)
; when(boundp('pbLocal) pbLocal='unbound)
);prog
printf("*Ex2* pbGlobal = %L\n" pbGlobal)
t
);proc
printf("exmple2()\n")
;

When procedure is complete, pbGlobal=nil in both cases. So, they are
bound.
If I try to unbound (remove from memory, when statement) inside
procedure I get this: *Error* eval: unbound variable - pbGlobal
SKILL Lint gives.
INFO (VAR5): Unrecognized global variables:
WARN GLOB (VAR8): pbGlobal
INFO (VAR): used: in function exmple1 from file pBox_examples.il,
lines (17 14 12)
INFO (VAR): used: in function exmple2 from file pBox_examples.il,
lines (38 35 33)
INFO (VAR): set: in function exmple1 from file pBox_examples.il,
line 15
INFO (IQ): IQ score is 95 (best is 100).

What is correct way to remove this pbGlobal?

Thank You and Best Regards
Edis
 
edis105136@hotmail.com wrote, on 05/29/09 07:32:
On May 28, 8:45 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm
wrote:
edis105...@hotmail.com wrote, on 05/28/09 17:55:



Hi
I create progress bar box with hiDisplayProgressBox( ?name 'pb ...) <-
pb is any symbol correct?
I can set progress as it proceed with hiSetProgress( pb ++ii ) <- pb
should point to my progressBar?
But here pb is variable not a symbol. If I put 'pb (symbol) SKILL
parser reports an error.
If just pb (variable) everything fine, BUT.
After procedure is done, I get error report: *Error* unbound variable
- pb.
I placed pb as local variable, inside prog statement - another error
message appears on hiDisplayProgressBox( ?name 'pb ...) - Syntax
error...pb - nil
What and where can be wrong?
Thank you
-Edis
Whenever you create a top level user interface item (e.g. a form, a menu, a
dialog box, or a progress box) you need to give it a name. This name is the name
of a variable in which to store the structures for the user interface item.

The variable must be global (in general this is true, there are some exceptions
if you know what you're doing with a form - for example you display a blocking
form in the same scope that it's created). The reason being is that when the
interaction with the user interface item occurs, a SKILL expression is generated
to do the action - and this is recorded in the CDS.log file. The user interface
item knows the name of the variable (which is why you pass the variable name as
a symbol - it then knows the name of the variable it is stored in). If the
variable was a local variable at the time you created the item, it may not be in
scope by the time you interact with the form/progress bar etc.

So in this case, if you create the progress bar in a function with pb as a local
variable, and then try to reference the handle for it in a different scope, it
may not be bound.

The best thing is therefore to make it always global.

Note that user interface items which are not top level (e.g. menu items, form
fields etc) do not need to be stored in global variables (or even in variables
at all) because they are accessed via the top level UI structure.

Sorry if I got my terminology mangled in places - I wrote this in a rush and
didn't take enough care to ensure everything was clean and consistent...

Best Regards,

Andrew.

Thank you, Andrew
Here are 2 exmples. Please, advise which one is correct.

procedure( exmple1(@optional (var1 500000))
prog( ( pbLocal)
; .
hiDisplayProgressBox(
?name 'pbGlobal ; <- creates global variable
?banner "Collecting cells"
?text sprintf( nil "Please, wait..." )
?totalSteps var1
?autoClose 't
);progress
for( ii 0 var1
hiSetProgress( pbGlobal ++ii ) ; access to global
);for
printf("*Ex1* pbLocal = %L pbGlobal = %L\n" pbLocal pbGlobal)
when(boundp('pbGlobal) pbGlobal='unbound)
);prog
printf("*Ex1* pbGlobal = %L\n" pbGlobal)
t
);proc
printf("exmple1()\n")
;
procedure( exmple2(@optional (var1 500000))
prog( ( pbLocal)
; .
pbLocal=hiDisplayProgressBox(
?name 'pbGlobal ; <- creates global variable
?banner "Collecting cells"
?text sprintf( nil "Please, wait..." )
?totalSteps var1
?autoClose 't
);progress
for( ii 0 var1
hiSetProgress( pbGlobal ++ii ) ; access to global
);for
printf("*Ex2* pbLocal = %L pbGlobal = %L\n" pbLocal pbGlobal)
; when(boundp('pbLocal) pbLocal='unbound)
);prog
printf("*Ex2* pbGlobal = %L\n" pbGlobal)
t
);proc
printf("exmple2()\n")
;

When procedure is complete, pbGlobal=nil in both cases. So, they are
bound.
If I try to unbound (remove from memory, when statement) inside
procedure I get this: *Error* eval: unbound variable - pbGlobal
SKILL Lint gives.
INFO (VAR5): Unrecognized global variables:
WARN GLOB (VAR8): pbGlobal
INFO (VAR): used: in function exmple1 from file pBox_examples.il,
lines (17 14 12)
INFO (VAR): used: in function exmple2 from file pBox_examples.il,
lines (38 35 33)
INFO (VAR): set: in function exmple1 from file pBox_examples.il,
line 15
INFO (IQ): IQ score is 95 (best is 100).

What is correct way to remove this pbGlobal?

Thank You and Best Regards
Edis
Click to expand...
Neither, really, although the first is closest. There's little benefit in
setting pbGlobal to 'unbound - it gets automatically set to nil when the
progress box is closed, so that the structure can be garbage collected. It makes
little difference whether pbGlobal is nil or unbound - it's still in the symbol
table, so I don't see much point in setting it to unbound.

There's no point in the second example in setting the return value of
hiDisplayProgressBox to a local variable - effectively pbLocal and pbGlobal are
pointing to the same value. Setting pbLocal to unbound will leave the value of
pbGlobal completely unaffected (variables are essentially pointers to values -
and when you change the value of a variable, you're actually setting the
variable to point to a new value, and so other variables pointing to the same
value aren't affected).

In SKILL Lint, you should use an uppercase prefix. If you do that, you'll be
able to specify the prefix list in SKILL Lint as (say) "PB". So if you have
PBglobal, it will then allow you to have a global variable without complaining,
or marking you down. We generally recommend customers to use uppercase prefixes
because Cadence uses lowercase prefixes. However, it is possible to specify a
lowercase prefix for SKILL Lint provided you first do:

skIgnoreMessage('STRICT)

Regards,

Andrew.
 
On May 29, 12:56 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
edis105...@hotmail.com wrote, on 05/29/09 07:32:



On May 28, 8:45 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm
wrote:
edis105...@hotmail.com wrote, on 05/28/09 17:55:

Hi
I create progress bar box with hiDisplayProgressBox( ?name 'pb ...) <-
pb is any symbol correct?
I can set progress as it proceed with hiSetProgress( pb ++ii ) <- pb
should point to my progressBar?
But here pb is variable not a symbol. If I put 'pb (symbol) SKILL
parser reports an error.
If just pb (variable) everything fine, BUT.
After procedure is done, I get error report: *Error* unbound variable
- pb.
I placed pb as local variable, inside prog statement - another error
message appears on hiDisplayProgressBox( ?name 'pb ...) - Syntax
error...pb - nil
What and where can be wrong?
Thank you
-Edis
Whenever you create a top level user interface item (e.g. a form, a menu, a
dialog box, or a progress box) you need to give it a name. This name is the name
of a variable in which to store the structures for the user interface item.

The variable must be global (in general this is true, there are some exceptions
if you know what you're doing with a form - for example you display a blocking
form in the same scope that it's created). The reason being is that when the
interaction with the user interface item occurs, a SKILL expression is generated
to do the action - and this is recorded in the CDS.log file. The user interface
item knows the name of the variable (which is why you pass the variable name as
a symbol - it then knows the name of the variable it is stored in). If the
variable was a local variable at the time you created the item, it may not be in
scope by the time you interact with the form/progress bar etc.

So in this case, if you create the progress bar in a function with pb as a local
variable, and then try to reference the handle for it in a different scope, it
may not be bound.

The best thing is therefore to make it always global.

Note that user interface items which are not top level (e.g. menu items, form
fields etc) do not need to be stored in global variables (or even in variables
at all) because they are accessed via the top level UI structure.

Sorry if I got my terminology mangled in places - I wrote this in a rush and
didn't take enough care to ensure everything was clean and consistent...

Best Regards,

Andrew.

Thank you, Andrew
Here are 2 exmples. Please, advise which one is correct.

procedure( exmple1(@optional (var1 500000))
prog( ( pbLocal)
; .
hiDisplayProgressBox(
?name 'pbGlobal ; <- creates global variable
?banner "Collecting cells"
?text sprintf( nil "Please, wait..." )
?totalSteps var1
?autoClose 't
);progress
for( ii 0 var1
hiSetProgress( pbGlobal ++ii ) ; access to global
);for
printf("*Ex1* pbLocal = %L pbGlobal = %L\n" pbLocal pbGlobal)
when(boundp('pbGlobal) pbGlobal='unbound)
);prog
printf("*Ex1* pbGlobal = %L\n" pbGlobal)
t
);proc
printf("exmple1()\n")
;
procedure( exmple2(@optional (var1 500000))
prog( ( pbLocal)
; .
pbLocal=hiDisplayProgressBox(
?name 'pbGlobal ; <- creates global variable
?banner "Collecting cells"
?text sprintf( nil "Please, wait..." )
?totalSteps var1
?autoClose 't
);progress
for( ii 0 var1
hiSetProgress( pbGlobal ++ii ) ; access to global
);for
printf("*Ex2* pbLocal = %L pbGlobal = %L\n" pbLocal pbGlobal)
; when(boundp('pbLocal) pbLocal='unbound)
);prog
printf("*Ex2* pbGlobal = %L\n" pbGlobal)
t
);proc
printf("exmple2()\n")
;

When procedure is complete, pbGlobal=nil in both cases. So, they are
bound.
If I try to unbound (remove from memory, when statement) inside
procedure I get this: *Error* eval: unbound variable - pbGlobal
SKILL Lint gives.
INFO (VAR5): Unrecognized global variables:
WARN GLOB (VAR8): pbGlobal
INFO (VAR): used: in function exmple1 from file pBox_examples.il,
lines (17 14 12)
INFO (VAR): used: in function exmple2 from file pBox_examples.il,
lines (38 35 33)
INFO (VAR): set: in function exmple1 from file pBox_examples.il,
line 15
INFO (IQ): IQ score is 95 (best is 100).

What is correct way to remove this pbGlobal?

Thank You and Best Regards
Edis

Neither, really, although the first is closest. There's little benefit in
setting pbGlobal to 'unbound - it gets automatically set to nil when the
progress box is closed, so that the structure can be garbage collected. It makes
little difference whether pbGlobal is nil or unbound - it's still in the symbol
table, so I don't see much point in setting it to unbound.

There's no point in the second example in setting the return value of
hiDisplayProgressBox to a local variable - effectively pbLocal and pbGlobal are
pointing to the same value. Setting pbLocal to unbound will leave the value of
pbGlobal completely unaffected (variables are essentially pointers to values -
and when you change the value of a variable, you're actually setting the
variable to point to a new value, and so other variables pointing to the same
value aren't affected).

In SKILL Lint, you should use an uppercase prefix. If you do that, you'll be
able to specify the prefix list in SKILL Lint as (say) "PB". So if you have
PBglobal, it will then allow you to have a global variable without complaining,
or marking you down. We generally recommend customers to use uppercase prefixes
because Cadence uses lowercase prefixes. However, it is possible to specify a
lowercase prefix for SKILL Lint provided you first do:

skIgnoreMessage('STRICT)

Regards,

Andrew.
Click to expand...
Thank you, Andrew for explanation.
Best Regards
Edi.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top