World: r3wp

I harness VID and let it layout like it should.  ;-)

you could almost say I abuse it  ;-) hehe

right now I am plugging liquid directly within.  yet another layer 
of abuse... but it works.

actually, liquid is currently so tight, its trying to update the 
gadget before its even displayed...

cause it receives an event during the init.

is there a sure-fired way to know if a face is currently shown?  
I don't remember from the top of my head... anyone?

would checking for none? parent-face be sufficient?

viewed?

I don't see that as being a word within the face.  could it be show?

I mean, could it be the attribute:  'face/show?

>> help viewed?
USAGE:
    VIEWED? face

DESCRIPTION:
     Returns TRUE if face is displayed.
     VIEWED? is a function value.

ARGUMENTS:
     face -- (Type: object)

ahhh...  sourcing viewed? and then find-window, I can say that it 
all relies on parent-face being set... just what I tought...

Maxim, you will need to check face/show? for this face and every 
parent up to the window. Then... umm... you might have to check the 
window differently, see if it it's in the screen-face/pane.

so face/show? becomes true once its been shown at least once?

yes, find-window will tell me if the panes/window its in is currently 
opened.

Yes. Hiding can be done with:
face/show?: false
show face/parent-face

Ah.. but you will basically need to make a function similar to find-window 
in order to be sure everything's ok.

Yes, you will need to check if parent-face is none. face/parent-face 
is only set the first time a face is shown.

yeah... but it never gets cleared... that's one of my pet peeves 
about view/face.

So you want to redraw a face, while respecting its show? facet, I 
suppose.

its hard to get JIT information on real state of faces.

I want to make sure that I don't try to call show on a face before 
its been initialised...

currently checking parent-face seems to work fine.

btw, GLayout sets parent-face in advance... allowing child face the 
chance to take decisions based on their parent... before the layout 
is done.

The user who rips a face out of a face hierarchy will have to be 
sure to also set the parent-face to none.

is it possible to see which browser is the default browser? BROWSE 
seems to be able to get to it.

on Windows it gets it from the registry

anyone know the way to programatically select one of any viewed windows? 
 I am trying

view find-window face 


on a face from a window I'd like to automatically select, but its 
not working...

hehehe  I just discovered a window face option I didn't even knew 
existed  :-)  I guess its "rather" newish?

'activate-on-show


Maybe I just never needed it before... but this does what I need. 
 :-)

hum... seems the rate system is buggy? when opening window popups... 
sometimes the rate for all window go dead... re-opening the same 
window, in the exact way will randomly stop/enable 'time events? 
 

has anyone ever seen this?

See also: face/changes dialect [activate minimize maximize restore]

After setting face/changes to one of those words, you must show the 
window face to do it.

I think I've seen weirdness with time events like that, but never 
got around to documenting the bug because it would have taken too 
long to describe it fully.

where is the changes dialect documented? do you know?

AFAIK nowhere :/ Add 'offset to dialect words.

In my own little text file that I collected over the years. :)

Thanks Rebolek. I had written a face/changes: [offset] example somewhere... 
it's supposed to attempt hardware scrolling, if graphic card supports 
it.

stupid question... can't we set the progress bar value directly within 
the dialect?

view layout [progress 0.3]

I find it a bit ugly to have to do this:

view layout [prg: progress do [prg/data: 0.3]]

>>  view layout [progress with [data: 0.3]]

why didn't I think of that... I used the 'WITH block all the time...

but still the 'with block is the "hack" method.  I was surprised 
to notice that we still cannot reach the decimal value within the 
1.3.2 release... there is an error lingering since years in VID.

hehe :)

the switch case, which reaches the face's multi object, has a decimal 
element, but its not of the proper type, so it never gets matched...

meaning, although it should be able to address a decimal function 
within the multi object, it never does cause the switch which should 
trigger the case, will never match.

that's strange

I remember giving the solution to Carl... and he replying....   "Oops!" 
hehe

this might predate RAMBO... maybe the fix never got included in the 
release, or its there and my latest code is just not trying to use 
the proper function within the multi object...

so will you RAMBO it? 1.3.3 is right behind the door... ;))))

I'll try to find where its going wrong...

just found it... its in the grow-facets VID func:


			pair!   [append pairs val]
			integer! [append pairs val]
			string! [append texts val]
			tuple!  [append colors val]
			block!  [append/only blocks val]
			file!   [append files val]
			url!    [append files val]
			image!  [append images val]
			char!   [new/keycode: val]
			logic!  [new/data: new/state: val]
			decimal! [new/data val]
			time!   [new/rate: val]

note how the decimal! type is not properly set!

I'll RAMBO it right away.