World: r3wp

Terry, I found some Agent code in HAL 4000 package. Looks pretty 
similar to other demos I have seen. I don't see what exactly I'm 
doing wrong there. I am very suspicious about the TTSModeID setting 
not working. I'll have to follow that up at some stage.

Thanks for your test.

Does the ado stuff work with this new beastie? http://www.microsoft.com/sql/ctp_sqleverywhere.mspx
.

No idea. Do you need it ?

I guess the question is: does COMLib work with ADO.NET ?

I think that depends on whether ADO.NET supports the older ADO interface 
or not.

A better question is whether COMlib supports OLEDB, which is COM-based. 
SQL Everywhere works with OLEDB too.

Well, if it really is COM based, then I imagine it should work.

COMLib website update:
Added outlook-calendar.r and outlook-contacts.r demos.
Fixed a few bugs in the main rebol interface file, COMLib.r
http://home.wilddsl.net.au/anton/rebol/os/windows/COMLib/

Robert, have a look at the outlook demos.

Not yet, sorry, was busy. I will. Thanks for posting this stuff.

And, as I don't use OL myself, I need to setup a test system.

Anton, is there a way to use Com and OneNote?

Not sure on this. The postings I find about the COM interface in 
OneNote a few years ago make the interface sound very lacking. Not 
sure it's much better now a few year have gone by or not.

Is there any way to get around the fact that Rebol faces are not 
native Windows "windows"? (i.e. don't have a handle on the system). 
Speech recognition command & control does not work with Rebol apps 
as long as that is the case and I need that...

Hmm.. the system port can be used to trap windows messages, perhaps 
if the command & control uses windows messages you can handle them 
that way... Can you give more information about the speech recognition 
software used ? (Is it MS software ? etc..)

The Speech Reco software is the one that comes built-in with Windows 
XP and Windows Vista (BTW, speech reco in Vista is much better than 
in XP). It analyzes widgets on the screen by running through all 
the windows handles (just about everything on a Windows screen is 
a window) and their labels, so it actually knows there's a menubar 
with a file menu on it so you can do things like say "Menu" "File" 
"Open" and it simply works for almost all native apps. It sends the 
equivalent commands by sending Windows messages to the windows. Problem 
is, since Rebol widgets do not have their own handles, the system 
never finds them, doesn't know they're there or that messages can 
be sent to them...

I think that's a tough one.

It would probably be easier to wrap the Speech API and use it directly.

That ouwl defeat the purpose; the idea is that the system works for 
all apps and that the apps themselves do not need to do anything 
to have it. Wrapping the API and then building it into every single 
app is not a feasible option. Do you think it's possible to adapt 
the Vid and RebGUI dialects to integrate with the SPeech API so everything 
built with those at least would work? (don't know much about how 
dialects work yet)

That's a big job, I'm afraid.

I don't know of anyone that's wrapped the ability to use native Windows 
controls in a REBOL dialect, though it *might* be possible. I think 
Cal (and maybe Cyphre or Oldes) have emebedded native OS windows 
in a View window. You might also be able to do it by creating your 
own windows, using the API, and then interacting with them behind 
the scenes. It would be a lot of work though, and be highly OS specific.

Yes, with the DLL interface you can theoretically create native-like 
GUI system according to your needs if you have enough time/motivation 
;)

While maintaining the flexibility of VID/rebGuI ?

If you write VID/RebGUI like dialect with binding to Windows native 
GUI why not? :)

hmm, not sure Cyphre, but you are the guru. Does windows has anything 
like face? If you would use only its windowing system, it is just 
what win32API allows you - dialogs, etc. - so no such flexibility, 
unless you would code View like compositing yourself

Cool :)

Pekr: You can create and control any windows dialog if you have the 
API available. (and this can be applied to any other OS feature). 
So it is possible to create native GUI controlable at the higher 
level of some dialect(simmilar to VID/Rebgui). People who are making 
common apps don't need to access it at face level but ofcourse such 
system would be based on face-like objects with methods related to 
Windows GUI elements etc.

the same could probably be done for OSX/Cocoa... it would solve many 
issues with GUI nativity in OSX.

If you really need noative GUI then this can be the way but remember 
this is also *lot* of work multiplied by each operating system ;)

which is why it's probably not worth doing for anything other than 
Windows and OSX. For linux, it would be ... wow... how many different 
GUI systems do we have there? :-)

(But for example Java has already such toolkit and IIRC it is huge 
opensource  Eclipse tool platform supported by IBM)

http://www.eclipse.org/swt/

http://www.eclipse.org/swt/widgets/

Using native windows will go to greatly improving the success of 
View based programs in the commercial sector.

because they don't have to ask "why does the program look so weird?"

Using native Windows will certainly kill View completly

We use top systems - SAP - they have own look, completly, even behavior 
to some elements - noone complains ..... we have Lotus Notes - very 
different look to most of apps, different navigation to app ....

for me, RebGUI, look-wise, is very Windows like .... yet some of 
us, including you, Graham, complained that it looks dull, and if 
it could be prettified .... :-)

pekr, I don't believe so. View is essential for those 5 minute apps 
that you need to do for a friend.

of course, maybe it just depends, how professional you intend to 
be, but as I showed you, completly OS compatible look is not so important. 
What is imo more important is the feel. If we can't get visual representation 
of accelerator keys, ctrl tab, rich text, key precise behavior for 
ui elements, that is what I see as a problem ....

... that can be fixed imo, if View gets fixed in those respective 
areas ....

Just look for e.g. ad Ad-aware vs. Spy and Destroy. Spy & Destroy 
was chosen by many as better, yet I can see ppl chosing Ad-aware, 
because of different look actually ...

the question is, with Google and others pushing the envelope, how 
long OS itself will be driving factor of IT evoluion, or it will 
become a commodity :-)

Yes, in specific commercial sector people expect the 'conservative' 
look&feel. But  this feature should be provided as an external solution 
mainy due the increase of binary size of Rebol in that case. I think 
sch module would be for about 2MB in size.

I think time of "amiga" (in the sense of non traditional look to 
apps), is coming back in Internet age ...

ok, then, I can accept your pov. But - wouldn't fixing View plus 
providing certain skin be enough?

I agree that native GUI/feel should not be a main part of Rebol, 
but it should not be a luxury item either that you have to pay for

From my POV  View is still very ligthweight and powerful system for 
OS independent solutions.

I think that what Henrik feels as a problem is not actually "look" 
at all, but it is the "feel", which is the culprit. I expect UI elements 
as drop-down, etc., react to keyboard, mouse, just the same as if 
it would be OS app, or it is denerving, stopping my productivity, 
which is based upon certain customs ....