Hello everyone,

We seem to having an issue with the SetCueBanner() method in both 
XbpCombobox and XbpSLE classes.

The error will look like this:

oError:args         :
           -> VALTYPE: O CLASS: _XbpCombobox
           -> VALTYPE: N VALUE: 0
           -> VALTYPE: N VALUE: 5377
           -> VALTYPE: N VALUE: 0
           -> VALTYPE: N VALUE: 0
oError:canDefault   : N
oError:canRetry     : N
oError:canSubstitute: Y
oError:cargo        : NIL
oError:description  : Parameter has a wrong data type
oError:filename     :
oError:genCode      :          2,00
oError:operation    : :SendOSMsg
oError:osCode       :          0,00
oError:severity     :          2,00
oError:subCode      :       1025,00
oError:subSystem    : BASE
oError:thread       :          1,00
oError:tries        :          0,00
==============================================================================
CALLSTACK:
------------------------------------------------------------------------------
Called from XBPCOMBOBOX:SETCUEBANNER(919)
Called from XBPCOMBOBOX:CREATE(861)
[Rest of call stack is irrelevant is think]


We've been seeing these errors for quite a while now (at least 2 years, 
probably longer). Problem is we cannot reproduce them and they only 
happen occasionally. With around 700 customers and from 1 to 10 PC's per 
customer, we get about 5 to 10 errorlogs per day from diffent sites.
They occur on all Operating Systems, from XP to Win7 and TS Server 
2003/2008 on all Xbase versions we have used. We are at the latest 
version now.


The strangest thing is that we do not use a Manifest file at all. So the 
CueBanner doesn't even do anything (and so we never use any).
The errors occur on different dialogs in different parts of the 
application, in dialogs created in code as well those created by XppFD, 
so I don't think it's a wrong parent/owner kind of problem.

I have seen in \source\SYS\xbparts.prg the call is the following:
::SendOSMsg( ::GetHWND(1), EM_SETCUEBANNER, 0, 0 )

And I am wondering:
1) What is parameter 1 doing in ::GetHwnd()
2) Why is ::getHwnd() returning 0?
3) Has anyone seen this before or have an idea as to how to solve this?

As I said, we dont use any cueBanners, so If I could just disable the 
code it would be fine too.

Thanks,
Sebastiaan

hi,

what Xbase++ Version we are talking about ?
did you read PDR 6083

> The strangest thing is that we do not use a Manifest file at all.

try use Xp Manifest and look what IsThemeActive() return

> As I said, we dont use any cueBanners, so If I could just disable the code 
> it would be fine too.

as you say you have found it in XPPSYS.PRG so try to disable it there

p.s. did you use Hotfix 23 ?

greetings by OHR
Jimmy

Op 2-12-2011 20:45, AUGE_ OHR schreef:
> hi,
>
> what Xbase++ Version we are talking about ?
> did you read PDR 6083
>
>> The strangest thing is that we do not use a Manifest file at all.
>
> try use Xp Manifest and look what IsThemeActive() return
>
>> As I said, we dont use any cueBanners, so If I could just disable the code
>> it would be fine too.
>
> as you say you have found it in XPPSYS.PRG so try to disable it there
>
> p.s. did you use Hotfix 23 ?
>
> greetings by OHR
> Jimmy
>
>
As I said, all Xbase version so far, and we always use the most recent 
version including patches. So right now 1.90.355.

I don't see what Hotfix 23 or PDR 6083 have to do with this problem.
The PDR is about cuebanners not showing and I don't want any so that's 
OK. I juist don't want the error.
The Hotfix is installed btw.

But the last suggestion is what I was thinking about myself, only 
problem is I didn't know how to do it, but I've now found I can build a 
custom XPPSYS.DLL.
That could be a solution, but I do'nt think it should be a permanent 
one, that would mean keeping our DLL up-to-date with Alaska 
version/modifications on every update and possibly hotfix.

If all else fails I will give it a try...

hi,

> I don't see what Hotfix 23 or PDR 6083 have to do with this problem.

just think "reverse" what will "hide" Cuebanner to be active e.g. "Far East 
language extensions"

yes i agree better would be a general Fix but for this you need to send a 
Sample to Alaska how to reproduce your Error ... if they can reproduce it 
...

greetings by OHR
Jimmy

Sebastiaan <-@-> wrote in message news:3b13a263$2c47c655$1498e@news.alaska-
software.com...
>As I said, all Xbase version so far, and we always use the most recent 
>version including patches. So right now 1.90.355.
>
>I don't see what Hotfix 23 or PDR 6083 have to do with this problem.
>The PDR is about cuebanners not showing and I don't want any so that's 
>OK. I juist don't want the error.
>The Hotfix is installed btw.
>
>But the last suggestion is what I was thinking about myself, only 
>problem is I didn't know how to do it, but I've now found I can build a 
>custom XPPSYS.DLL.
>That could be a solution, but I do'nt think it should be a permanent 
>one, that would mean keeping our DLL up-to-date with Alaska 
>version/modifications on every update and possibly hotfix.
>
>If all else fails I will give it a try...

Hello Sebastian,

we have the same problem and don't know how to solve it!

Xbase++ Version     : Xbase++ (R) Version 1.90.355
Betriebssystem      : Windows XP 05.01 Build 02600 Service Pack 3
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: O CLASS: AchsenNumEdit
          -> VALTYPE: N VALUE: 0
          -> VALTYPE: N VALUE: 5377
          -> VALTYPE: N VALUE: 0
          -> VALTYPE: N VALUE: 0
oError:canDefault   : N
oError:canRetry     : N
oError:canSubstitute: J
oError:cargo        : NIL
oError:description  : Parameter hat falschen Typ
oError:filename     : 
oError:genCode      :          2
oError:operation    : :SendOSMsg
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :       1025
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von XBPSLE:SETCUEBANNER(1407)
Aufgerufen von XBPSLE:CREATE(1349)

Since we are using the new compiler 1.90.355 with all bugfixes (until 44 
except 37) the problem occured with WinXP and Win7.
We are using approx. 1100 mobil Computers and 800 Computers as Clients on 140 
Servers. Our Operating Systems are WinXP, Win7 and Windows Server 2003.

Did you find a solution? Is there any workaround I can use? What did you do?

Greetings and thanks in advance,
Georg

Op 7-3-2013 7:46, Wolfgang Moldenhauer schreef:
> Sebastiaan<-@->  wrote in message news:3b13a263$2c47c655$1498e@news.alaska-
> software.com...
>> As I said, all Xbase version so far, and we always use the most recent
>> version including patches. So right now 1.90.355.
>>
>> I don't see what Hotfix 23 or PDR 6083 have to do with this problem.
>> The PDR is about cuebanners not showing and I don't want any so that's
>> OK. I juist don't want the error.
>> The Hotfix is installed btw.
>>
>> But the last suggestion is what I was thinking about myself, only
>> problem is I didn't know how to do it, but I've now found I can build a
>> custom XPPSYS.DLL.
>> That could be a solution, but I do'nt think it should be a permanent
>> one, that would mean keeping our DLL up-to-date with Alaska
>> version/modifications on every update and possibly hotfix.
>>
>> If all else fails I will give it a try...
>
> Hello Sebastian,
>
> we have the same problem and don't know how to solve it!
>
> Xbase++ Version     : Xbase++ (R) Version 1.90.355
> Betriebssystem      : Windows XP 05.01 Build 02600 Service Pack 3
> ------------------------------------------------------------------------------
> oError:args         :
>            ->  VALTYPE: O CLASS: AchsenNumEdit
>            ->  VALTYPE: N VALUE: 0
>            ->  VALTYPE: N VALUE: 5377
>            ->  VALTYPE: N VALUE: 0
>            ->  VALTYPE: N VALUE: 0
> oError:canDefault   : N
> oError:canRetry     : N
> oError:canSubstitute: J
> oError:cargo        : NIL
> oError:description  : Parameter hat falschen Typ
> oError:filename     :
> oError:genCode      :          2
> oError:operation    : :SendOSMsg
> oError:osCode       :          0
> oError:severity     :          2
> oError:subCode      :       1025
> oError:subSystem    : BASE
> oError:thread       :          1
> oError:tries        :          0
> ------------------------------------------------------------------------------
> CALLSTACK:
> ------------------------------------------------------------------------------
> Aufgerufen von XBPSLE:SETCUEBANNER(1407)
> Aufgerufen von XBPSLE:CREATE(1349)
>
> Since we are using the new compiler 1.90.355 with all bugfixes (until 44
> except 37) the problem occured with WinXP and Win7.
> We are using approx. 1100 mobil Computers and 800 Computers as Clients on 140
> Servers. Our Operating Systems are WinXP, Win7 and Windows Server 2003.
>
> Did you find a solution? Is there any workaround I can use? What did you do?
>
> Greetings and thanks in advance,
> Georg

Hi Georg,

Good question, I had almost forgotten about this problem because there 
haven't been any complaints from users as far as I know...
I've just checked our errorlogs and the number of errors has indeed gone 
down substantially, to about 20 in the last months of 2012 and only 3 
errors so far (on 3 different clients) in 2013...
But we haven't changed anything relevant in the code that we know of, so 
the cause and solution is still unknown to me.
But since the numbers of errors has gone down I suspect it might even 
have something to do with different client/Windows settings, or even a 
Windows update, a virusscannner update... no idea....
On the other hand, the error still occurs so there is still a bug, but I 
don't know how to solve it.
Are your errors more frequent?

Sebastiaan

>Hi Georg,
>
>Good question, I had almost forgotten about this problem because there 
>haven't been any complaints from users as far as I know...
>I've just checked our errorlogs and the number of errors has indeed gone 
>down substantially, to about 20 in the last months of 2012 and only 3 
>errors so far (on 3 different clients) in 2013...
>But we haven't changed anything relevant in the code that we know of, so 
>the cause and solution is still unknown to me.
>But since the numbers of errors has gone down I suspect it might even 
>have something to do with different client/Windows settings, or even a 
>Windows update, a virusscannner update... no idea....
>On the other hand, the error still occurs so there is still a bug, but I 
>don't know how to solve it.
>Are your errors more frequent?
>
>Sebastiaan

Hi Sebastiaan,

to be contrary to your experience, we have established that this bug still 
exist and the number of exceptions isn't decreasing! But I can't also tell 
you how frequent this happened.

Our sourcecode at this position isn't very clear und structured. We deceided 
to change a bit at our code.
We hope, if we optimized our sourcecode, the number of exceptions would 
decrease. With the optimized code we can remove one needless class-hierarchy.

I guess mid 2014 we had more information concerning our try.

greetings
Georg