[Bug 36854] Divinity Original Sin Gog version does not display graphics after patch

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=36854

--- Comment #26 from Karol Herbst <wine at karolherbst.de> ---
(In reply to Ken Thomases from comment #25)
> (In reply to Karol Herbst from comment #24)
> > currently I try to understand the ToUnicodeEx function a bit more:
> > 
> > example ^^:
> > IN ^ OUT -1 "^"
> > IN ^ OUT 1 "^" (though windows prints ^^)
> > 
> > example ^a:
> > IN ^ OUT -1 "^"
> > IN a OUT 1 "â"
> > 
> > example ^p:
> > IN ^ OUT -1 "^"
> > IN p OUT 2 "^p"
> 
> I'm not entirely sure what the above means. In particular, the input to
> ToUnicodeEx() is a keystroke along with the key state, but you show a
> character.
> 
yeah, I know. I just meant the virtual keys, which are translated to the
characters.
> > I have some questions here:
> > 1. should the first call produce a "^" translation? If not, are there
> > special characters, which should be used for X11?
> 
> I'm not sure what you're asking. First, nothing X11-specific should be
> returned to the caller of ToUnicodeEx(). It's a Win32 function, so the
> behavior should be as close as possible to the behavior on Windows (except
> that the user's keyboard layout may differ on the two platforms).
> 
> When ToUnicodeEx() returns -1, it indicates that the key was a dead key. The
> buffer should contain the (non-dead) character which corresponds to the dead
> key. For example, the app may display that character (perhaps with a special
> color or style) to indicate the pending dead-key state.

I see.
> 
> > 2. should in the ^p example the second call return "^p", if the first
> > question answer is yes?
> 
> I believe so, yes. The first keystroke was a dead key. The second keystroke
> does not combine meaningfully with that dead key. So, the dead key becomes
> just a normal character. Plus the second keystroke produces a normal
> character. So, the call returns both characters.
> 
> > In the first version I would only care about the first example and use the
> > third one also for ^a (this can be changed later I guess).
> 
> I didn't understand this.

I meant, that I will ignore the "â" case and just put "^a" into the out buffer
for now. If this works I will add support for the "â" case.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.