World: r3wp

if you don't do a call to do-events, it won't be modal (blocking 
events to the main window)

if you feel like it, you can just look at the show-popup and hide-popup 
 mezz source code and improve it to let it do what you need.

the only issue here is that if you try to do use a title'less window, 
it won't obay the "stay in front" property... strange.

the only thing to know is that the default wake-event is pretty dumb 
in how it manages the exit application condition when a windows is 
closed.

so if you do play around or make your own show-popup style commands, 
you will probably have to insert a line or two into the main wake-event 
so it knows not to close the whole event port when you close your 
custom stay-in-front windows.


note that these windows CAN resize... VID 2 just never allowed us 
to control it in the popup code.

that creates a modal window

no.

I have to fix view everytime I use my own requestors... its pretty 
quickly designed code which was patched by Gabriele in later VID, 
but even those changes, break up pretty quickly.

for a window to be modal, a new call to wait must be done at some 
point.

part of the modality is managed in wake-event IIRC.

but for a fact, just looking at the wake-event function for view, 
show-popup and hide-popup  you have ALL of what you need to make 
View manage windows the way you want it.


(I've had to play in there countless number of times... GLayout completely 
removes show-popup, for example.  and adds a /modal refinement to 
its 'view command instead)

When a mouse button is held down and the mouse is moved it triggers 
"over" events, during which a right mouse button event is ignored. 
In windows, either mouse button being pressed will cause the system 
to stop triggering "over" events. Does anyone know how I could get 
this kind of behaviour?

Sorry, that should be "when the left mouse button is held down"

the over are sent to allow you to do drag events.

Yes, I know, but I wish to receive a right mouse button down while 
receiving left mouse over events.

I have to go to work.

How to determine if a font is installed?

This is the code I use for RebGUI:

get-fonts: make function! [
	"Obtain list of fonts on supported platforms."
	/cache file [file!] "Obtain fonts from file"
	/local s
] [
	all [cache exists? file] [insert clear fonts unique load file]
	if empty? fonts [
		either OS = 'Win [

   call/output {reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows 
   NT\CurrentVersion\Fonts"} s: copy ""
			s: skip parse/all s "^-^/" 4
			request-progress/title (length? s) / 3 [
				foreach [fn reg style] s [
					fn: trim first parse/all fn "("
					all [
						not find fonts fn

      not find ["Estrangelo Edessa" "Gautami" "Latha" "Mangal" "Mv Boli" 
      "Raavi" "Shruti" "Tunga"] fn
						not find fn " Bold"
						not find fn " Italic"
						not find fn " Black"
						not find fn "WST_"
						insert tail fonts fn
					]
					wait .01
					step
				]
			] "Loading fonts ..."
		] [
			call/output "fc-list" s: copy ""
			s: parse/all s ":^/"
			request-progress/title (length? s) / 2 [
				foreach [fn style] s [
					all [
						not find fonts fn

      (size-text make widgets/gradface [text: "A" font: make font [name: 
      fn size: 10]]) <>

      size-text make widgets/gradface [text: "A" font: make font [name: 
      fn size: 12 style: 'bold]]
						insert tail fonts fn
					]
					wait .01
					step
				]
			] "Loading fonts ..."
		]
	]
	sort fonts
]

thanks ... I knew that you had done something but a google search 
failed to find anything

MESSAGE TO ALL  :-)


I've finally found the way to drastically improve the overzealous 
mouse event handling within the lowest level of view directly without 
causing any noticeable side-effects in the normal face event handling.

its a small patch in view's wake-event function.


the only requirement is that you have at least one face (usually 
the window, if you can) which has a rate set to the response you 
need...  usually around 15 -20 is enough.


this makes face scrolling based on mouse mouse VERY smooth as there 
is no more lag ... which occurs because we can receive 2 to 3 times 
more events than view/AGG can refresh itself.

if you need this, please speak up, I'll gladly offer the recipe.

Maxim, why you aren't using the event compression technique from 
Gariele+Romano?

cause I don't know about it  :-)


and any I've tried before (which might include this one, I don't 
recall) created problems which forced me to adapt my code.

using the rate, I can with almost perfect precision measure that 
there will never be more mouse events than the rate which is set.

check this one: http://www.rebol.org/view-script.r?script=eat.rnot 
sure if the script is up-to-date but the technique described in it 
works pretty well.

and because the rate IS NOT triggered when REBOL is busy, it will 
actually send Less events on its own, making the trick scalable in 
real-time.

I will thanks.

tested...  in 2.7.6, at least, the example windows break up, the 
moment we touch some of the sliders .  ' :-/  


we might need to update the eat-event example for later view releases.

will try something...

no success... still causes errors.

Max, if the patch is small, can you post it for review?

Anyone know the reasons http://synapse-ehr.com/forums/showthread.php?31-Vid&p=237&viewfull=1#post237

hide is discarded,  because after having done the action, view do 
a show on the face, uhuhuhu.
try this instead.
>>view layout [ mbutton: button "hello" [face/size: 0x0] ]


but you have to remember the size indeed, for further showings of 
the button.

Because the problem may exist with other styles.
i suggest these 2 small mezz in replacement of hide and show.

vanish: func [face][face/size: negate abs face/size show face]
spook: func [face][face/size: abs face/size show face]

>> view layout [ mbutton: button "hello" [vanish mbutton] ]

enjoy :)

Nice .. rebgui doesn't have these issues

because SHOW is not native in RebGUI.

It is actually.

Steeve is not quite correct to say that "view do a show on the face". 
It is VID which does the SHOW, which you can see here.
>> print mold get in svv/vid-styles/button/feel 'engage
RebGUI probably does not use this code.

Correct.

Right Anton, but I am perjured myself later, saying (the problem 
may exist in other styles). :)

Ashley, sorry, I'm working from the RM-Asset version. :-)

a way around it, would be to do a "soft show": all [face/show? show 
face]. this can be installed in feel/hot in the vid-feel.r file, 
if you have access to the VID sources.


also using size 0 would not work in the VID Extension Kit when resizing.

Is there a way to get anti-aliased fonts in an area?

only by using DRAW and that is quite difficult. (just ask shadwof) 
better to wait for R3 for this.

I need to detect capslock and alt-key events.  Does anyone know if 
this can be done?

I think not ... more about events:

http://www.rebol.com/how-to/feel.html
http://www.rebol.com/docs/view-face-events.html

What about R3?

Not sure low level code changed in that regard ... I will try to 
ask Cyphre. We imo definitely need to add support for combinations 
like ctrl + tab, etc.

It's unrealistic to expect people to do without alt-keys. They're 
used in practically all programs as hotkey components. With respect, 
there should be a way to do this.

Rebol opens a system port, that is to say a port with scheme 'system, 
but when I look in system/schemes there is no system scheme.