AltME groups: search

Put a HALT at the end of the script. If you want to see the console, 
simply print something like PRINT "finished"

Ok, that was weird!  I just started View and it told me there was 
a new version to be downloaded and when I clicked download it popped 
up a file requester asking me where I want to download view.exe to. 
 The weird part is the default path it popped up was C:/Program Files/Common 
Files/System/Mapi/1033/NT  Where the hell did that come from?

Hm...  Somehow VIEW is triggering my Virus Scan Software...  Not 
sure just what is going on but when I run View 1.2.125 it is telling 
me that there is a new version of View available and immediately 
thereafter my Virus Scan is popping up a requester claiming files 
that I KNOW aren't viruses are viruses.

I just ran the View desktop, and was advised of a newer version.. 
which I duly downloaded.

REBOL/View 1.3.0.3.1 10-Jun-2005 Core 2.6.0
Copyright 2000-2005 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM

I guess it might be worthwhile waiting for LNS to do a library interface.

Is there a "proper" way to set font properties for a single element, 
such as 'text after the layout is created?

I'm trying:
view layout [a: text "12345" b: text "12345"]


and set the font size for a: a/font/size: 14 (b is 12 at this point)

then I unview it and:
view layout [a: text "12345" b: text "12345"]
once more. Now b has font size 14 as well.

They seem to share the same font object....

Henrik, in these cases you need a local font object.

and set the font size for a: a/font/size: 14 (b is 12 at this point)

 <--- I don't set a to a/font/size there although it looks that way, 
 sorry.

should be "and set the font size for the variable a to: a/font/size: 
14"

I'm not sure just how that changed, Ashley, but I did hear some talk 
somewhere here about execution of user.r being removed because its 
a security issue...

A and B share the same, so what you need to do is

view layout [a: text "12345" font-size 14 b: text "12345"]  ?

a/font: make a/font [size: 12]

After that, you simply can A/FONT/SIZE: 13

Shadwolf, yes, you're right. Today VID is a bit loosing the focus 
in favour of REBOL/View 1.3.0 and probably RebGUI, but I'm sure there 
will be efforts again.

Yes, it's a whole new approach.

We must IMOO  have a widget set that is similar than what are  people 
habbits and be smoother and able to be distinguish directly

we abstract from OS capabilities and set of widget and we introduce 
a commun set

That's right, shadwolf. My approach was more of the kind of simulating 
existing OSes, I had a need for that.

I am developing a better listview myself... hopefully it'll be generally 
useful in a few weeks

As I said - I can definitely tolerate different look. It is imo even 
vital to be slightly different. Today that is once again a trend 
- just look at Ad-aware for e.g. But - ppl will not tollerate that 
well, if app behaves differently, commone keys don't work etc. - 
that is my experience ...

Chris your code can be bettered more people will work on it more 
sharp it will be and if we have as goal to include it into a state 
of art basement library like rebGUI I think this will be very enthousiastic 
for people who will participate ;)

I make a listview widget multicolumn multi resizing with drag&drop 
Viewed bar effet like in Win32API and multi widget type capable in 
only 3 weeks and using less than 300 That's the illustration that 
REbgui and VID base concept are pretty good  !!

our point with ashley is to gatherring the VID widgets de effort 
into a single process

christianE: what it does is I create simply a fixed grid of textboxes 
and replace the text in them on the fly. that's much faster than 
setting offset for a very big pane. this way it doesn't matter how 
big the list is, it'll stay fast

Since the very beginning of VID we have seen lot intent of widgets 
improvements make by pationnated people but we never take the time 
to enclose those work into a trully thinked system that's why we 
don't have a reable and durable widget design effort and RebGUI  
tryes to fit this need

PANE is a function I guess, hence no scrolling involved.

that doesn't mean that we can't anymore work on our side to search 
for better widgets and better interactivity system but havng RebGUI 
 improvement as goal makes our work to have a meanning

right now there still are a ton of functionality improvements to 
come, and it'll be even faster than it is now. I want to implement 
dynamic column sizing, graphics in lists, drag'n'drop and proper 
handling of list actions

shadowolf: ok... mine is still a bit backwards. I have a list object 
which contains all list functions and the raw layout for the list. 
when I want to use the list, I create a box in a layout and assign 
it to the pane of that box, voila. :-) the list adapts to the size 
of the box, so I think live resizing would work though columnsizes 
are still fixed

rebgui works like that you fill the pane field of the box with all 
your needed widgets and then you make a show box and voila ;)

layout is a translation stage ...  this is not usefull you lost CPU 
time and memory for not a real gain ;)

When I was working on MDP-GUI some month ago basing me on the very 
first intent of ashley we were using a layout compositor (and a layout 
call) to renderize the docuement view than Ashley comes with a design 
based on pre contructed minimal enherited face system and using only 
show the gain inthe do view area rendendering process was about 300 
%:)

yu have some primitive object based on a father object (make face) 
 and then there sons inhert and enhance there capabilities

actually it is possible to decompose a face to any dialect, it's 
just not built in and an exercise for an expert. ;-)

Pekr layout is a dialectal parser so he treat the key work (consoming 
CPU and if you have a lot of widget to renderise like into a MD view 
area or a list it's a nightmare...) and the used widgets are the 
VID default ones with lot of unneeded thing ...

a: box 300x300 ... a/pane: layout heavy-list-of complicated-widgets 
and a: box  ... insert tail  a/pane tiny-widget then show a are not 
the same

when you work with layout you have a loop that create in the VID 
dialectal compliant way the futur content of a/pane then you have 
a second loop (layout) that treats the VID dialect content of you 
temporary object to insert the result into the pane and then you 
have show that draw on screen what you have on the box/pane buffer 
;)

using premade face you avoid the compositing of the VID layer you 
fill the pane field and realize it on scree with show ( so you have 
2 loops intead of having 3 loops using the layout methode an once 
again layout is good for tiny composed interface but for complicated 
interface that's a too long way to do  ;)) )

VID  use a translation process and REbgui on use it once to make 
the window first design but then not any more for the design ;)

Yes, that's what I meant: But VID wouldn't need a layout parser, 
too, if weren't as stylizeable than it is. As far as I know, RebGUI 
*by design* doesn't support different styles and therefor is by design* 
faster.

That's a different approach with different goals in mind.

and easier if you "only" need a tradition GUI ?

yes but when you manipulate in VID you are very tempted to pass by 
stylize/master you premade object then put them with the good args 
into a buffer then renderize the buffer using layout and show ;)

Ammon yes but display is a concatenation of view/new layout  ;)

you can do a: box ... than a/pane: display [subwidget organisation 
] there is no need to do that

because you have the insert tail a/pane [ object widget not dialect] 
show a capability :)

you can have fancy things as soon as the basement and the whole system 
design allow it without impacting on perfs ;) But that's a true design 
effort ;)

I'm absolutly convinced that draw/AGG capabilities open to us a true 
amazing scope of posibilities

pekr make the try take a very frirst version of MDP-GUI and take 
the lastest  You will be suprise ;)

Hi Petr, hi shadwolf. Back agin. Petr, just FYI (and mine, too) I 
had a quick look: MOLD/FLAT makes 43 KB from my source file, COMPRESS 
MOLD/FLAT leaves some 9'500 bytes ;-)

Yes, Petr, if you use VID correctly, you setup your UI *once*, and 
this must done either way. That's why today's apps often have a long 
load time and entertain the user with a splash screen.

I think I will file a bug - that is not normal, or I just don't wish 
it would be normal - Rebol really can't block system buttons during 
its internal activity. That is weird, imo wrong and annoying.

no, that's not the same principle, in Cyphre demo I used "engage: 
func [f a e][switch a [time [something]]]....." so it renders ONLY 
when time-event comes, in Rebcircle is "engage: func [f a e][something]...." 
so new image is rendered on every event.

Pekr: for different bookmark icon (left bar in desktop), there is 
a "Reset bookmark" script in the Rebol.com/tools folder. See Carl 
advice in the note of this release http://www.rebol.net/notes/rv13-changes.html#section-3

Back in the pre 1.3 beta, we have got async kernel inside REBOL for 
a while. I would like to ask, if it solved open/skip, open/seek features, 
so that projects like RebDB could proceed? Thanks ....

is it possible to have a transparent backdrop in a pane? I'm creating 
a box with some interactive elements in its pane, and I want to see 
what's under the box

petr: yes, it does. a /seek port operates differently from a /direct 
port. you can try it out on any beta with the async core (i.e. view 
1.2.57)

I notice the new view 1.3 request function now allows the keyboard 
to select an answer.  So, for an alert, a space bar is enough.
how can I get the same functionality with the sdk?

Another easy question, I have a login screen that starts off with

view center-face loginscreen


How do I make it so that the userid field has focus?  At present 
I have to use the mouse to activate the userid field before I can 
type.

REQUEST is a mezzanine, so you can SOURCE it and patch it into your 
code.

Was just exploring the REBOL/Desktop and ran into a summary document 
of changes for 1.3.  Don't recall seeing this referenced from other 
sources... http://www.rebol.com/docs/changes-view.html

Anyone know if there is any updates to the new /view such that we 
can activate a button and run a forever loop and still not inhibit 
view events? I don't want to have to use a wait command if I can 
help it.

I can't think of anything, but would wait really be that much of 
a hinderance?  Especially since even wait .0001 works.

Now that View 1.3 is out, does anyone know what the roadmap is ? 
 I would have thought it would be easiest to first release the SDK, 
then LNS, then IOS which may rely on LNS, and then OSX View?  Anyone 
got a better path?

The following used to work with View 1.2:


 view a: layout [btn 200x200 [view/new/options layout [btn 100x100] 
 reduce ['parent a]]]

but no longer works under 1.3. A bug?

ashley: i think it's a bug. not sure if it's in rambo though.

1.3.0a is a test release. fixes a number of bugs (one important security 
bug in particular). if no new bugs are found there, it will be released 
as 1.3.1.

is there a list of bugs?

I was happy to see "request-dir" as I was updating a 6-year old tool 
that I use off and on. I was wondering if, for sake of continuity, 
there is a "windows" gui for this?

Paul: Would  using a timer work for you? .. or launch the process 
in a new window. which probably isn't desirable.

Here is a simple e.g of using rate. (I'm sure you've already thought 
of this)
forever-block: [
	print now/precise
]

View layout [
	tm: led :forever-block
	area "so you test editing while process is running"

 t: tog "Start Process" "Stop Process" [either (face/text = "Start 
 Process") [tm/rate: 0:00:00] [tm/rate: none] show tm]
	"Stop Process" [tm/rate: 0 show tm]
]

It states in link http://www.rebol.com/docs/changes-view.html, that 
a new modal system is used in 1.3 and will be developed further. 
 Maybe you need to specify now that the child window needs to stay 
infront?

I think it's a bug as an alert should stay in front, and they don't 
now.

Just got a message to update my View.

Well, that's not good. Is it listed as a bug in RAMBO?

Carl, regarding no longer a one man band...

Anything to announce on the arrangement you have made with these 
members of the community?  Is it a permanent one or temporary, etc?

Before you eat .. when can we see a new SDK?

BB in a while. Bye!

hm. Okay, I get lots of code with "source ctx-edit", but I can't 
figure out how to get it into a file. I keep trying stuff like --> 
write %edit.r source ctx-edit

No, its just a block. simply save it. dont use 'source.

'editor looks for ctx-edit and if it a block, it makes it a context 
(saves a bit memory when not used.

Anyone know what happened to all the registry functions in View 1.3?


   create-reg      native!   Creates a registry key and returns TRUE 
   on success...

   delete-reg      native!   Deletes a registry key. Returns TRUE if 
   deleted. (...

   exists-reg?     native!   Returns TRUE if registry key exists. (HKCU 
   is defa...

   get-reg         native!   Returns value of a registry key, else NONE. 
   (HKCU ...

   list-reg        native!   Returns a block of sub-keys for a registry 
   key. (H...

   set-reg         native!   Sets registry key value. Returns value 
   on success,...
   unset-reg-funcs function! []

I hope they aren't gone for good!

registry access wasn't for user REBOL/View - it's a Windows only 
/Command feature. As they are used in installation, these were exposed 
in alpha/beta builds, but "internal" funcs aren't available in official 
release...
You can note the registry access is/was incomplete: 
- only string! datatype is available, not dword

- how one lists the values under a key? 'list-reg only returns sub-keys, 
not values.

Yeah I posted a feedback asking for more support with windows registry 
and especially remote registry capabilities since many of the things 
I do are accessing remote computers in the enterprise.

I think the upgrade utility should drop the acknowledgement "name 
of the file" part as it looks sloppy because I saved the file as 
"view2.exe" because the currently file couldn't be overwritten and 
it said I saved the file as "view.exe".  Just gives a bad impression 
of what else might be buggy.

MikeL and Ashley thanks - I have used Frank's registry.r before but 
think that RT should just add those in and expand them a bit as they 
work very well.

Gregg:  I asked for these in a feedback before so I assume its not 
very high on the priority list.

Gabriele: I have noticed you don't use 'get-face but ctx-access/panel/get-face* 
in your %survey.r script.

I have tried the both, and yes 'get-face does not work. Is this a 
known bug (not in RAMBO then) ?

I'm sitting on a 256 color screen through a WindowsXP Remote Desktop 
and Viewtop looks like crap. Therefore I was thinking if some recommended 
coloring policy would be beneficial for low-colored devices, or if 
REBOL/View could have a scheme to intelligently map colors down?


I know REBOL can't know that it's being used in a low-colored environment 
like Remote Desktop, but you could specifically map colors down in 
a layout, if you know your app will run on a poor display device.


Something like layout/depth and then a number from 2-32. It would 
be useful also for generally mapping down images. How does that sound?

Didec: hard to say if it's a bug or not. should windows have the 
panel accessors? i think they should, but maybe others don't. anyway 
it's likely a good idea to put it in rambo so that we don't forget... 
adding it now.

it's because you could set-browser-path to any exe, even a virus 
you just downloaded :)

thanks a lot, Anton ... I also wonder about following I have two 
layouts, I have small search dialog, then I have grid displaying 
the result. I use button action block, when I call btn "search" [view 
lay2 focus f] - and I wonder - how is that the focus f part is executed? 
I am glad it works, just don't understand it, I thought that by view 
lay2 events will not allow processing focus f ...

it is a task for VID 1.4 or 1.5 then - buttons have to be focusable!

LAYOUT does not DO-EVENTS a second time, therefore it does not "break" 
a block of code being done by ... wake-event (I think).

means on layouting. after that you have a big face and that initialisation-stuff 
is lost.

A while ago we had some fun "beeping" faces. IIRC Anton started that. 
He made an image! from some layout and played that as wave. Needs 
low memory in script, if you find a good one.

there is no grid ... I have just search field, focused, Close and 
Search button for mouse. If something is found, new layout appears 
- a grid, plus "focused" close button, which gets you back to first 
layout ...

lay1: layout [f: field [view lay2] btn "Quit" [quit]]
lay2: layout [text "just a try" btn "Return" [view lay1 focus f]]

view lay1

so is that a bug or what?

its the first time i see quit not quit. IMHO a bug.