World: r3wp

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.

please could it be done someway, that Desktop (or even upgrade function) 
would include auto-installatiion? If no installation was performed, 
then it would just switch .exes. So - new .exe would be downloaded. 
It would be launched, first running instance ended, new one copied 
to the place of first one, launched, and downloaded version deleted?

It is already nice we are offered new version, but would be even 
cooler if it would offer (we can ask user for that) to install after 
download. btw - change those old buttons on the upgrade dialog box, 
as it is incompatible with new button look we use for Dekstop ...

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.

Paul re: Windows Registry you might want to look up / find Frank 
Sievertsen's RegEdit.  It was dated 21-8-01

http://www.rebol.org/library/scripts-download/registry.r

Make sure any requests for changes get into RAMBO, otherwise they 
may fall through the cracks.

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.

..and probably didn't make it through to RAMBO and may have got lost.

Are there any plans (or capabilities that I don't know about) to 
have menu navigation from the services line of the View Desktop?

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.

Gabriele - what happened to variable set-browser-path?

not available for security reason.

ah. What was the risk? Ihave to notify Ashley then, he seems to be 
using it for RebDB

henrik: if the os controls the palette for the "screen", you'd be 
out of luck anyway.

the risk is that it's like call, without the security requestor :)

ah, then it is because of IE, no? You can launch apps via IE IIRC, 
not sure about others ...

but 'browse is still available, isn't it?

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

yes, browse should work as expected.

:-)

Gab: good.

Agree with Henrik - it will be nice to have second color scheme using 
only "safe" palette for example. Have seen Desktop in 256 colors 
too.

when I want my window to react upon ESC, do I still need to use insert-event-func?

can I give focus to button?

Or map enter key to the button?

hotkey? #"^/" ?

view layout [button #"^M" [print "action done."]]

ah, missed the quotes :-) it is ^M

Buttons can't be focused. You would have to stylize your own button 
to do this. I think it was Frank Sievertsen who long ago showed how 
to make CHECKs focusable and respond to keys: tab, space enter etc.

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 ...

(Sorry, buttons *can* be focused, they just don't feel good about 
it :)

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

yeah, that would be nice.

:-)

view layout [btn "search" [view/new center-face layout [h1 "results..." 
f: field] focus f]]

view layout [btn "search" [view center-face layout [h1 "results..." 
f: field do [focus f]]]]

well, don't want to have two windows, so I don't need view/new. Just 
wondering, that once I call view lay2 from lay1 and there is another 
function in button action block in lay1, it gets executed, although 
theoretically events should be in lay2 already, no?

ah, maybe it does not, sorry ...

good question. looking into layout ...

yes, it really does, just tried it ...

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

view only calls do-events when there is no window visible. in your 
button action it is, so view just returns and the 'focus is executed. 
(if that was your question).

yes, exactly. So everything in button action will be executed, right?

yes.