C / C++ / MFC

Manifest for DPI awareness.

18-Jun-19 11:41

Well, that really does not explain what is happening. Perhaps if you showed (in your original question) the actual code and the values that cause the problem ...

Maximilien17-Jun-19 9:25

Maximilien

17-Jun-19 9:25

In visual Studio, I can change the DPI Awareness in the Manifest Settings (Manifest Tool -> Input and Output )

Is it the same thing as setting it in the manifest file ?

Thanks.

I'd rather be phishing!

Re: Manifest for DPI awareness.

Richard MacCutchan17-Jun-19 20:50

Re: Manifest for DPI awareness.

17-Jun-19 20:50

Yes, add the following lines just below the root (<assembly>) node:

<asmv3:application>
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <dpiAware>true</dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>

Maximilien18-Jun-19 4:42

Maximilien

18-Jun-19 4:42

That's what I am doing.
Thumbs Up | :thumbsup:

Thanks.

I'd rather be phishing!

getchar / putchar - how does it really works ?

Vaclav_15-Jun-19 6:49

Vaclav_

15-Jun-19 6:49

My task is to input individual characters , terminate the input with "space" or "ESC" and then retrieve / save the characters entered.

getchar and its variety waits in loop (?) and outputs to stdout until "enter" key is pressed.

putchar outputs ( to stdout) EACH character entered in do { ...} while loop - runs the loop.

Questions
1. Is there a way to terminate getchar other than entering "enter "?
2. How does putchar "runs" in do { .. } while loop ignoring getchar?
3. How can I "retrieve" characters in WHAT buffer for additional processing AFTER the do{} while loop is terminated ?

C++

char next;
do
{
next = getchar(); // outputs each character as entered
putchar(next);    // outputs characters in loop
}
while (next != '\n'); // terminates with enter key press / new line /n

Richard MacCutchan15-Jun-19 7:03

15-Jun-19 7:03

Vaclav_ wrote:
getchar and its variety waits in loop (?) and outputs to stdout until "enter" key is pressed.

No, getchar merely reads the next character entered at the terminal. If the terminal is in (normal) echo mode then it displays the character as typed. The putchar function merely displays a character, it has no knowledge of the loop or anything else.

1. Yes, you can terminate on anything, just inspect the character as entered and compare it to your terminator.
2. As above, putchar does nothing beyond displaying a single character.
3. Save them somewhere.

Vaclav_15-Jun-19 8:34

Vaclav_

15-Jun-19 8:34

I am seeing this

C++

char next;
do
{
next = getchar(); // outputs each character as entered
cout << "text entered " << endl;
putchar(next);    // outputs characters in loop
}
while (next != '\n'); // terminates with enter key press / new line /n

qwerty            
text entered 
qtext entered 
wtext entered 
etext entered 
rtext entered 
ttext entered 
ytext entered

k505415-Jun-19 9:07

k5054

15-Jun-19 9:07

you need to turn off canonical mode on input. man termios, and look for ICANON. As a quick test without recompiling:

$ myprog
qwerty
text entered 
qtext entered 
wtext entered 
etext entered 
rtext entered 
ttext entered 
ytext entered 

$ stty -icanon
$ myprog
qtext entered 
qwtext entered 
wetext entered 
ertext entered 
rttext entered 
tytext entered 
y
text entered 

$ stty icanon

See: [FAQ - Cprogramming.com](https://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1045691686&id=1043284392)

Richard MacCutchan16-Jun-19 3:02

16-Jun-19 3:02

It seems that reading characters one at a time is no longer possible (on Windows). While getchar returns the characters one at a time, the system does not present them until after the enter key was pressed. So although you are trying to read single characters, they are still streamed internally.

[edit]
Same result on Ubuntu.
[/edit]

modified 16-Jun-19 13:01pm.

leon de boer16-Jun-19 5:43

leon de boer

16-Jun-19 5:43

It has nothing to do with windows Smile | :)

Whoever writes the C/C++ library determines how it works, you are making a C/C++ standard call not a windows call and if they don't do the standard then it is hardly a fault of windows.

On windows really the easy way is to hook the WM_CHAR and/or WM_SYSCHAR messages because the message queue is available even in console apps since windows XP service pack 2.

In vino veritas

Richard MacCutchan16-Jun-19 5:48

16-Jun-19 5:48

I know that, I was merely pointing out its behaviour on Windows as opposed to Linux.

Stefan_Lang16-Jun-19 21:29

Stefan_Lang

16-Jun-19 21:29

Richard MacCutchan wrote:
the system does not present them until after the enter key was pressed.

Not quite true, or at least not complete: if there is something in the input buffer already, getchar will immediately return with the next char it finds in that buffer. It will only wait if the input buffer is empty. AFAIK this is not dependend on the OS.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Richard MacCutchan16-Jun-19 21:48

16-Jun-19 21:48

Well that is exactly what happened in my tests, none of the characters were retrieved until the enter key was pressed.

leon de boer17-Jun-19 2:43

leon de boer

17-Jun-19 2:43

No it doesn't always it depends on the canonical mode of your input, this was covered above.
The C standard doesn't cover how the underlying system is operating and it cant present what it doesn't yet have.

Richard simply has an OS that is in canonical mode.

In vino veritas

Stefan_Lang18-Jun-19 5:13

Stefan_Lang

18-Jun-19 5:13

Well it always worked as I described for me. But I admit I haven't heard of the canonical mode before, so I'm going to trust you on this.

Change Icon

JM225113-Jun-19 18:12

JM2251

13-Jun-19 18:12

Hi,
There are icon for Maximize and Restore Down on Wondow Title.
Can I change Maximize icon to Restore down on button click?

Re: Change Icon

Richard MacCutchan13-Jun-19 21:32

WM_MOUSEWHEEL message and the Touchpad : SOLVED thanks to Randor

13-Jun-19 21:32

Yes, but you need to do all the drawing of the frame and title bar. Take a look at WM_NCPAINT message - Windows applications | Microsoft Docs[^].

Richard MacCutchan13-Jun-19 4:28

13-Jun-19 4:28

I am processing the WM_MOUSEWHEEL messages in a C++ application,

C++

void CView::OnMouseWheel(
    HWND    hWnd,
    int	    xPos,
    int	    yPos,
    int	    zDelta,
    UINT    fwKeys
)
{
    zDelta /= WHEEL_DELTA;	// calculate the number of lines to move
    if (zDelta != 0)
    {
        // line up or down once per delta
        OnVScroll(hWnd, NULL, zDelta > 0 ? SB_LINEUP : SB_LINEDOWN, 3);
    }
}
</blockquote>

but when I use the touchpad nothing happens. Following the advice in the MSDN documentation I divide the zDelta value by 120 (WHEEL_DELTA) to calculate the (approximate) number of lines to scroll. The debugger shows that the resulting value is always zero. If I use my mouse and turn the wheel it scrolls correctly. The weird part is that using other applications (VS, Word, Chrome etc.) the touchpad works correctly. So I conclude that the code should somehow get some other information that identifies the touchpad, and adjusts the delta accordingly. Anyone else seen similar problems?

[edit]
Thanks to David D's sugestion I modified the code to accumulate deltas that are less than the value of WHEEL_DELTA, thus:

C++

static int myDelta = 0;
if (abs(zDelta) < WHEEL_DELTA)
{
    myDelta += zDelta;
    zDelta = myDelta;
}
zDelta /= WHEEL_DELTA;	// this value works better than WHEEL_DELTA;
if (zDelta != 0)
{
    myDelta = myDelta % WHEEL_DELTA;  // save the remainder for further movements
    // line up or down once per delta
    OnVScroll(hWnd, NULL, zDelta > 0 ? SB_LINEUP : SB_LINEDOWN, 3);
}

which works a treat.

Note that I use the value 3 for the number of lines to scroll. In a proper commercial application the code should use the value of the system parameter: SPI_GETWHEELSCROLLLINES.
[/edit]

modified 14-Jun-19 9:09am.

Gerry Schmitz13-Jun-19 9:26

Gerry Schmitz

13-Jun-19 9:26

I found the mouse wheel events specific to the "mouse wheel".

When using only touch (tablet swipe) I got the scrolling, but the "wheel event" that I used to detect "at bottom or top" no longer fires and I need to find something else. I think it now has to tie into a "view changing" and / or "view changed" event and / or manipulation started / ended.

(And I think a touchpad is treated as a "pointer" in Windows 10).

The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects

Richard MacCutchan13-Jun-19 21:19

13-Jun-19 21:19

The messages are coming through correctly, but the delta value is always less than 120. That is unless I give a fast swipe from top to bottom of the pad. I have checked the parameters sent with the message and, apart from the delta value, they are the same for the mouse or the touchpad. More debugging required I expect.

Richard MacCutchan14-Jun-19 1:04

14-Jun-19 1:04

The touchpad is just a mouse to the system, but it sends WM_MOUSEWHEEL messages somewhat differently. I have added the solution to my original post.

Gerry Schmitz15-Jun-19 5:36

Gerry Schmitz

15-Jun-19 5:36

Glad you got it working.

Yes, "delta" is a double, so it has quite a range.

I needed the "Manipulation events" which give scroll direction and distance.

Richard MacCutchan15-Jun-19 6:58

15-Jun-19 6:58

The strange thing was that using both the debugger and Spy++, I could not 'see' the multiple messages coming in. In both cases after a scroll gesture on the touchpad, they both showed just one message and then went back to the application window. So it as if the delta values were just too small.

BTW, thanks for your interest.