World: r3wp

What happens when you call the same functions in C or C++?

I haven't try. There are their Ex variants, imo related to dialog 
boxes. In fact I haven't tried anywhere in the source call to those 
funcs. So maybe those are called from dialog boxes.

That would be the definitive test whether the problem is in the Red 
binding or not

LedSetDlg.cpp does:

fpSetLanguage(m_nLanguage);//set language  1= chinese english=3

why would it be a proof?

Maybe there's no default language so that's needed. Or the default 
is Chinese and you don't have Chinese support installed or something 
like that

You don't know if the C functions don't do the very same thing as 
the Red binding

m_nLanguage = 0; //for auto

I wrapped a dialog box call, as DLL can cal e.g. LSN_BrightDlg, and 
it opens in English. When I explicitly call a language setting function, 
later on, set/get brightness still crashes ... I will see moving 
to the PC, where the sending card to LED screen actually is.

OK, enough for this weekend. Thanks for the assistance :-)

If you haven't tested this on the machine with the hardware, anything 
is possible. That's why calling the C functions would have tested 
such things

I tested it initially also on that machine. As I said - I was able 
to turn screen on/off, to get is-power? returning proper values ....

That means #import basically works for this library, so the other 
functions should also be able to be made to work

The Ex function variants are not about dialogs. They take an extra 
integer parameter for the screen number, when there are multiple 
LED screens

The sample code uses the Ex functions. There may be a bug in the 
simple functions, so you should try the Ex functions instead

CLedSetApp::InitInstance() does this:

#ifdef _AFXDLL

 Enable3dControls();			// Call this when using MFC in a shared DLL
#else

 Enable3dControlsStatic();	// Call this when linking to MFC statically
#endif

I don't know why that would affect communication with the device, 
but since the library itself contains MFC dialogs, it may need one 
of these initialisation functions

(See also: Not REBOL) In this way, RED could be renamed to ROD with 
many positive and complex connotations :)

ROD in modern Slavic mythology is a god of birth and of ansectry.

And RED is a color of war (including a nuclear war).

Rodit' in Russian means 'to give a birth'.

I'm thinking about deriving my own (simpler) ROD from RED :) All 
in all---Slavics must deal with their own mythology, and I am Slavic 
:)

Definitely ROD will be simpler than RED.

I don't need C influence there.

note that currently, what you see isn't RED... its RED/System.

Of course

This preprocessor is a BIG step BACK for a REBOL-like language and 
is completely counterproductive, and I can prove and explain why. 
I have a lot of insights into this issue.

Regardless of whether it's RED or R/S, it's highly counterproductive.

I find a code with preprocessing TERRIFIC, AWFUL, and TERRIFYING. 
It slows down compilation to orders of magnitude.

#include must be replaced by IMPORT or DEPENDENCIES

Since compilation of included file is done everytime, and for IMPORT/DEPENDENCIES 
it is done once, and then a compiled version of a dependency is used 
everytime, which is infinite orders of magnitude faster.

#define may be replaced by MACRO keyword (more specific) or by DEFINE 
keyword (if you want to use a broad term). # is redundant and ***misleading*** 
since it makes one think it's C #define.

why not use the simple

define macroname: macrovalue

syntax

?

#if and #either are easily replaceable by "if" and "either" with 
an optimising compiler

and are completely redundant

#switch is the same as #if/#either.

So, all preprocessor directives can easily be removed from a language 
of Red/System, and replaced by normal keywords.

They give no pros, and give only slowdown of a translator and also 
much greater complexity of a code (try to analyse it metaprogrammatically 
and you will understand what I tell about!) and they also give a 
redundant extra layer of complexity.

I propose to start a RED v2

Red/System v2. Without a preprocessor directives at all.

Not if it delays RED

Haha. So you advicate a sShort time progress with Eternal

oops

Sorry. So you advocate a short time progress with Eternal regress 
and pain of recompiling included files and unavailability of metaprogramming 
possibility? No-preprocessor languages can easily be analysed metaprogrammatically 
and transformed, and preprocessor languages cannot (almost).

That's very childish, then. Uninformed decision.