Message unknown: "Warning: initial dialog data is out of range."

[Udo Huebner]

Hi all -

does anybody know where the message
"Warning: initial dialog data is out of range."
comes from?

I got it obviously while debugging my program and
saw it later in the info window.
I am using Visual C++ 6.0 on Windows 98SE.

Thanks in advance and regards Udo

[Doug Harrison [MVP]]

Udo Huebner wrote:

Search for it in the MFC source code, and ye shall find it emitted by
various DDV functions.

--
Doug Harrison
Microsoft MVP - Visual C++

[Dave]

it means the initial value you assigned to a variable that was linked to an
edit control (maybe others) was not in the range that you assigned for
validating that variable. most likely you assigned a range check to a
variable in the class wizard but forgot to go into the constructor for the
dialog and assign an initial value, or if you put in a value maybe you
changed the validation range later.

"Udo Huebner" <udo.h...@t-online.de> wrote in message
news:cgdagl$7h6$07$1...@news.t-online.com...

[David Lowndes]

>does anybody know where the message
> "Warning: initial dialog data is out of range."
>comes from?

The MFC DDV code called when your dialog is initialised with variables
outside the range you've specified for the validation.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Joseph M. Newcomer]

I'd suggest getting rid of any DDV stuff and do it yourself. You avoid these sorts of
messages. It means that you have an out-of-range value for your (probably edit) control.
But I find the whole DDV mechanism a poorly-implemented misfeature, since it causes
meaningless messages like this to be issued. I prefer to (a) avoid anything resembling an
explicit UpdateData anywhere in my code and (b) do my own validation on-the-fly rather
than waiting for inappropriate events when UpdateData does its (obscure) thing.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Udo Huebner]

Udo Huebner schrieb:

> Hi all -
>
> does anybody know where the message
> "Warning: initial dialog data is out of range."
> comes from?

Thanks all for the comments.

UpdateData is indeed in this program as a relic from
my very beginning as a programmer.
Obviously, I should take it out. :-(

Regards Udo

[Doug Harrison [MVP]]

Udo Huebner wrote:

>Thanks all for the comments.
>
>UpdateData is indeed in this program as a relic from
>my very beginning as a programmer.
>Obviously, I should take it out. :-(

I'd hate for you to adopt the belief that "UpdateData bad", so if you want,
see this message for more on the subject, which describes what it does, how
it's useful, when to use it, and when not to use it. Plus, it talks about
how to use dialog data variables correctly under DDX/DDV:

http://groups.google.com/groups?selm=2gadivke7i40q160u450tg2fprda23besl%404ax.com

[Udo Huebner]

Doug Harrison [MVP] schrieb:
> Udo Huebner wrote:
> ...

>>UpdateData is indeed in this program as a relic from
>>my very beginning as a programmer.
>>Obviously, I should take it out. :-(
>
> I'd hate for you to adopt the belief that "UpdateData bad", so if you want,

> ...

Doug -

thanks for the link and for the clarification contained.
I knew J.M.Newcomers argumentation for long and avoid
UpdateData nowadays using control variables.

Nevertheless, the search for the reason of the warning is
tedious in this bigger program. Is there any reasonable
methodical way?

Udo

[Doug Harrison [MVP]]

Udo Huebner wrote:

>Nevertheless, the search for the reason of the warning is
>tedious in this bigger program. Is there any reasonable
>methodical way?

Not that I know of. I always just search the source code. It's useful to add
a cookie such as the function name to each such message, so you can
distinguish messages which otherwise are duplicates. You can't do that for
MFC, but for your own code... On a related note, one of the worst things you
can do is throw an exception from many places and not tag it with more
context than the generic message string, which might be "Resource was not
available". Functions like AfxThrowResourceException(void) should be
avoided. In general, you'd be better off if they were defined as macros that
included the function name in the message with the __FUNCTION__ macro.

[Udo Huebner]

Doug Harrison [MVP] schrieb:

> Not that I know of. I always just search the source code. It's useful to add

> ...

Thanks again! Udo

[Joseph M. Newcomer]

I make it a design primciple that there is never, ever, anywhere in my code, the
possibility of getting the same message issued from two different places. Each site makes
sure it uniquely identifies itself, so if an issue is reported by a customer, the exact
line in the source code that issues the error can be identified. Often, as you point out,
it is simply an ID of some sort. For user-related errors, it is some word or phrase that
would convey meaning to the user; for internal errors, it is sometimes an error code,
sometimes a file/line, but it is always unique.

One of the things that is after all the years C and C++ has been around, there has never
been a compiler intrinsic current_function which is a string that is the name of the
function.
joe

Joseph M. Newcomer [MVP]

[Alexander Grigoriev]

Check __FUNCTION__ and __FUNCSIG__ macros in VC7

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:ad4qi091806vcq4uq...@4ax.com...

[Joseph M. Newcomer]

Wow! Now THAT is a useful feature! Wish the C standard had provided this, instead of it
being a Microsoft extension, but it is still an INCREDIBLE improvement!

Since I don't use VS7, I didn't see that! (It is too bad that a really nice compiler and a
really nice MFC have been made virtually inaccessible by an incompetently-designed GUI)
joe

[Doug Harrison [MVP]]

Doug Harrison [MVP] wrote:

>On a related note, one of the worst things you
>can do is throw an exception from many places and not tag it with more
>context than the generic message string, which might be "Resource was not
>available". Functions like AfxThrowResourceException(void) should be
>avoided. In general, you'd be better off if they were defined as macros that
>included the function name in the message with the __FUNCTION__ macro.

To add to that, while having the function name embedded in the exception
message is certainly useful, what if the function is called from a hundred
different places? You really have to take care to add tags to exceptions
before they propagate away from the context in which they occurred. The .NET
framework helps a lot by including a stack trace in its exceptions, but in
straight C++, I don't know how to do any better than writing some function
prologue/epilogue macros that catch well-known exception types, add
information to the error messages, and rethrow the exception. It seems like
the compiler could help some here, but AFAIK, it doesn't.

[Joseph M. Newcomer]

A prime example of this is the "storage leak" from strcore.cpp. About the most useless
messasge possible. Who allocated the string? That matters a lot. Some years ago I had to
make a 24/7 OS component actually be 24/7. Unfortunately, its exception mechanism did NOT
allow context to be added, and it was a real nightmare to figure out, at a high level,
when I got an error just where it came from, and consequently what the recovery would be.
This was not aided by the fact that all kernel calls on that OS failed by throwing an
exception rather than by returning an error code.

Ultimately nearly every function had an exception handler at the start of it, and the
entire body was executed in the context of that handler. The equivalent of __except then
issued a (shudder!) system console error message. Not a pretty solution at all, but after
a few weeks of bulky console logs, I got the reliability up to 24/7 and reduced the
messages to a dozen or so per day. So tagging really makes a difference.
joe

Joseph M. Newcomer [MVP]

[Martin Aupperle]

On Fri, 27 Aug 2004 14:45:17 -0500, "Doug Harrison [MVP]"
<d...@mvps.org> wrote:

>Doug Harrison [MVP] wrote:
>
[snip]

>but in
>straight C++, I don't know how to do any better than writing some function
>prologue/epilogue macros that catch well-known exception types, add
>information to the error messages, and rethrow the exception. It seems like
>the compiler could help some here, but AFAIK, it doesn't.
>

nearly. The problem here is that you need a try/catch/throw bracket
in every function. This uses MUCH resources and conflicts with user
defined try/catch/throw patterns, but what is worse, you need a macro
not only at the beginning but also at the *end* of every function.
This clutters the source, is ugly, can and will be forgotten by the
programmer and usualy is not exception safe.

Better solution is to have only one macro at the beginning of a
function, like

void f()
{
FSTART( "f" );

....

}

It defines a local object whose constructor pushes the function name
(and maybe other info) on a stack and the destructor pops it off. Now
if f throws, the stack trace is available.

Not really nice, but its easy, does not cost much
resources/performance, and does not impose anything on the exception
type. Can also be easily compiled out by defining FSTART to void(0)

Martin

------------------------------------------------
Martin Aupperle
------------------------------------------------

[Doug Harrison [MVP]]

Martin Aupperle wrote:

>Better solution is to have only one macro at the beginning of a
>function, like
>
>void f()
>{
> FSTART( "f" );
>
> ....
>
>}
>
>It defines a local object whose constructor pushes the function name
>(and maybe other info) on a stack and the destructor pops it off. Now
>if f throws, the stack trace is available.
>
>Not really nice, but its easy, does not cost much
>resources/performance, and does not impose anything on the exception
>type. Can also be easily compiled out by defining FSTART to void(0)

How do you write the dtor? I'd like the stack trace to be available to all
catch blocks along the call path. I guess uncaught_exception could help with
this, but it seems like you'd need to have a notion of "handling" the
exception, so you could dispose of the "frames" beneath the current one. It
seems you'd need to dispose of them whenever you catch an exception but
don't rethrow it, or you throw a new exception.

[Martin Aupperle]

>How do you write the dtor? I'd like the stack trace to be available to all
>catch blocks along the call path. I guess uncaught_exception could help with
>this, but it seems like you'd need to have a notion of "handling" the
>exception, so you could dispose of the "frames" beneath the current one. It
>seems you'd need to dispose of them whenever you catch an exception but
>don't rethrow it, or you throw a new exception.
>

Maybe I do not exactly understand the problem. Lets define

struct S
{
static std::vector<whatever> theStack;
S() { theStack.push_back( ... some context information ... ); }

~S() { theStack.pop_back(); }
};

The we can write something like

void f()
{
S __localS( "f" );

... Implementation of f ...

}

And do the same for every function of interest.
At ANY time (and therefore also in catch handlers at any level) you
can access S::theStack to get information about the call stack.

We use S::theStack when we throw. We pass it as an additional
parameter to the ctor of the exception object, where it is copied.

... some code in some function ...
if ( condition )
throw OdbcError( sqlStatement, .... some more stuff .... ,
S::theStack );

... more code of the function ...

This is oversimplified. We use some more information (like file name
and line numer, as well as user defined context information), dress
the functionality in some macros etc. But I hope you get the picture.


Hope that helps

[Doug Harrison [MVP]]

Martin Aupperle wrote:

OK, I guess I became confused when you said earlier, "does not impose
anything on the exception type". I was wondering how you pulled that off. It
looks like you didn't.