C / C++ / MFC

Re: Keeping UDS_ALIGNRIGHT positioning for an updown control after moving the buddy window

10-Feb-20 0:58

If you are adjusting size and position at run time, then you need to re-measure each control according to the new values that affect it. You also need to check any option settings on each control that may affect the layout. In your case the setting for UDS_ALIGNRIGHT will affect the control it is set on (the up/down) and the buddy window. See Up-Down Control Styles (CommCtrl.h) - Win32 apps | Microsoft Docs[^] for further information.

[edit]
You could load the resource dialog into memory and change the font details at runtime, and then invoke the dialog from the memory template. I am not 100% sure if that will work but a quick test should confirm it.
[/edit]

Alexander Kindel10-Feb-20 13:50

Alexander Kindel

10-Feb-20 13:50

Inserting the font details into the template would save me having to send WM_SETFONT to every control in the dialog that has text while handling WM_INITDIALOG, as I do now, but I don't see what difference it would make in positioning the controls. One of the tools I use to determine the layout is Button_GetIdealSize, which I Can't call until I have an HWND for each control in question. As far as I can tell, that means I can't do it until I've instantiated an instance of the dialog. I guess I could instantiate an instance at startup, position and size the controls, alter the template to reflect the siz and position values this yields, then destroy the dialog. That way, each time an instance of the dialog is instantiated from then on, the layout will already be correct from the start. It seems like a rather tortured usage of the API, though.

I'm not sure what you mean by remeasuring each control. Out of context, I'd have guessed that would mean calling GetWindowRect on each control, but I believe I know what values that would return a priori; it should zero out the struct if I do it before reformatting the control, reflecting the zeroed-out dialog template, and if I do it after reformatting, it should return the values I just specified. I'm similarly confused about what it means to check the control's option settings.

Re: Keeping UDS_ALIGNRIGHT positioning for an updown control after moving the buddy window

Richard MacCutchan10-Feb-20 21:59

How do people even do LL(k) parsing?

10-Feb-20 21:59

All that is necessary is to load the dialog resource into memory and change the font size and name in the dialog template. This would involve copying it from the loaded resource to a new memory location to allow for changes in the number of characters in the font name. The sizes of individual controls should not need any changes, as the Windows library handles converting dialog units to pixels. See LoadResource function (libloaderapi.h) - Win32 apps | Microsoft Docs[^] and Dialog Box Structures - Win32 apps | Microsoft Docs[^] for more information.

honey the codewitch9-Feb-20 7:24

honey the codewitch

9-Feb-20 7:24

I'm working on a project that involves an LL(k) parsing algorithm (or more accurately, a set of algorithms) which seem to be the best kept secret on the Internet.

The hunt for how to implement these took me back to C code written in 1989 and some citations for research papers dating back to 1992, which I can't seem to find a copy of the journal it was published in.

How do people even do LL(k)? How do they learn it? I understand how Terrence Parr (author of ANTLR) did as he has been instrumental in the crafting of LL(k) parsing algorithms for decades. He's no Aho & Ullman but he's a key player. He's the one that wrote that 1989 code I'm looking at.

I've found a few scattered research papers but the math is really heavy. You need a pretty advanced background in CS I think to understand it all.

But anyone else that wants to do this kind of thing? Good luck. If you can find the research it won't mean you can understand it, and I can't even find it, much less understand it. All the links are dead, and the citations I'm currently looking at lead to an out of print journal on information processing and information systems

It's ridiculous. No wonder there are so few implementations of this available (the major one by Terrence Parr himself)

Real programmers use butterflies

https://www.antlr.org/papers/allstar-techreport.pdf

Gerry Schmitz9-Feb-20 9:02

Gerry Schmitz

9-Feb-20 9:02

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food

honey the codewitch9-Feb-20 9:50

honey the codewitch

9-Feb-20 9:50

I'm surprised i didn't find that. I gues I should have dug around ANTLR's website. Thank you, this is a gem. Smile | :)

Real programmers use butterflies

Gerry Schmitz9-Feb-20 10:23

Gerry Schmitz

9-Feb-20 10:23

Sometimes they all start looking the same. Glad if it helps.

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food

Non-latin characters are shown correctly in Debug mode but not in Release

CPallini9-Feb-20 21:22

CPallini

9-Feb-20 21:22

Quote:
the major one by Terrence Parr himself

Who changes the 'damn thing' at each release in a way that irremediably invalidates the previous stuff... Roll eyes | :rolleyes:

sdancer754-Feb-20 3:34

Re: Non-latin characters are shown correctly in Debug mode but not in Release

4-Feb-20 3:34

Hi,

I am using an MFC dialog (ANSI no Unicode) created in the resource editor with a nonlatin character name in its title, as a Property page.

While running the debug mode I can see the nonlatin title in release mode I get a gibberish characters.

What seems to be wrong here?

sdancer75

Richard MacCutchan4-Feb-20 6:07

Re: Non-latin characters are shown correctly in Debug mode but not in Release

4-Feb-20 6:07

sdancer75 wrote:
What seems to be wrong here?

It is difficult to say without more information. Maybe some difference between Debug and Release settings. When you say "non Latin", what characters are you referring to?

sdancer754-Feb-20 6:24

Re: Non-latin characters are shown correctly in Debug mode but not in Release

4-Feb-20 6:24

Hi,

Thank you for your interest... Its the 1st time I meet this kind of problem. My Visual Studio is pretty old v2008 and the project settings are similar. Both Debug and Release share the same *.rc file.

They are both an MFC Static, not using ATL and Character Set are "not set".

My nonlatin character set is Greek. I can see the Greek titles in my dialog boxes in the editor. The only problem here is the Release version of the app. Don't know where to look for a problem.

Regards,

sdancer75

Richard MacCutchan4-Feb-20 6:52

Re: Non-latin characters are shown correctly in Debug mode but not in Release

4-Feb-20 6:52

I think the Greek character set requires Unicode to display correctly. Try changing the settings on your project.

sdancer754-Feb-20 20:48

Re: Non-latin characters are shown correctly in Debug mode but not in Release

4-Feb-20 20:48

Hi,

I have used older projects with Greek characters in ANSI and code pages without problems.

Indeed unicode will solve the problem, but this specific project is too big and I have to make too many changes to finally make it work fine.

Anyway, I managed to fix the problem changing the title of the title dynamically inside the code.

Take in mind that when I recall strings from the Resource String Table using CString.LoadString(ID) I get gibberish but when I am using CStringW.LoadString(ID) it works. My String Table is not Unicode but inside VS2008 I set it up as Greek code page.

sdancer75

Stefan_Lang5-Feb-20 21:41

Stefan_Lang

5-Feb-20 21:41

Two possible problems
1. In the project settings, make sure the character set is set to unicode for both debug and release
2. if you use third party libraries (other than MFC), make sure they also use unicode for both Debug and Release.

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)

Re: Non-latin characters are shown correctly in Debug mode but not in Release

sdancer755-Feb-20 23:12

Regular expression confusion (std::regex_replace).

5-Feb-20 23:12

Hi,

Thanks for your reply. Indeed I am using a 3rd party library but they are all set to ANSI (no unicode at all). I fixed the problem by dynamically changing the Dialog Title.

Regards,

sdancer75

Maximilien31-Jan-20 9:27

Re: Regular expression confusion (std::regex_replace).

31-Jan-20 9:27

(the pre tag seems to be broken with the code)

const std::wstring expression( L"Value stored = $(_VARIABLE_NAME_)");
const std::wstring tmp(LR"(\$\(([^\(\)\$]*?)\))");
const std::wregex rx(tmp);
const std::wstring variableValue(L"A2347X$01GBFC");

std::match_results<std::wstring::const_iterator> matchResult;
const bool found = std::regex_search(expression, matchResult, rx);
if ( found )
{
    const std::wstring expressionOut = std::regex_replace(expression, rx, variableValue, std::regex_constants::format_first_only);
    std::wcout << "expressionOut  = " << expressionOut << "!\n";
}

When I run the above code (or use Regex Tester )

(I added the bold)
expressionOut = Value stored = A2347X_VARIABLE_NAME_GBFC

I was expecting (or I am wanting) the result to be

expressionOut = Value stored = A2347X$01GBFC

Is there a way to treat the input "A2347X$01GBFC" as a "raw" input and not something to be parsed by the std::regex_replace ?

In our case, the string "A2347X$01GBFC" is something that a user can input manually.

I'm certain there is an way to do it, but I cannot see it.

Thanks.

I'd rather be phishing!

k505431-Jan-20 10:17

k5054

31-Jan-20 10:17

I can't see it either. It seems you've got two options, either use format_sed, if you know that you wont have \1 in the replacement string, or you'll have to turn any single $ into $$ before passing in to regex_replace There really should be a format_no_format flag to turn off format replacements.

Re: Regular expression confusion (std::regex_replace).

Maximilien31-Jan-20 12:21

Re: Regular expression confusion (std::regex_replace).

31-Jan-20 12:21

Awesome! Thanks.

Will try monday.

I'd rather be phishing!

Maximilien3-Feb-20 13:14

Re: Regular expression confusion (std::regex_replace).

3-Feb-20 13:14

The format_sed option seems to work; I will make the changes and push that to the test suites.

Thanks.

I'd rather be phishing!

k50544-Feb-20 3:35

k5054

4-Feb-20 3:35

Be aware that sed_format uses "\0" to replace matches. In your case if the user input was "A2347\01GBFC", you'd get the same output as for "A2347X$01GBFC" with format_default. If that's not an issue, then you're good to go.

Re: Regular expression confusion (std::regex_replace).

Joe Woodbury31-Jan-20 11:58

Joe Woodbury

31-Jan-20 11:58

Interesting. You could drop the capture group by eliminating the parentheses before the square bracket and after the question mark.

Edit: It seems the more correct way is to create a non-capturing group by adding "?:" after the group's opening parentheses:

const std::wstring tmp(LR"(\$\((?:[^\(\)\$]*?)\))");

Added: You could also scan the input and double up any dollar signs.

modified 31-Jan-20 18:06pm.

Re: Regular expression confusion (std::regex_replace).

Maximilien31-Jan-20 12:21

31-Jan-20 12:21

Awesome! Thanks.

Will try monday.

I'd rather be phishing!

gcov linker errors

Vaclav_30-Jan-20 9:05

Vaclav_

30-Jan-20 9:05

I have now build both project and its library using ARM architecture.
The library compiles and links - no error.
The library contains one test C++ class with only constructor / destructor implemented.
This is important to note - see the NOTEs at the end of the post.

The main program compiles but fails to link with errors indicating problem with "gcov".

The attached partial crosscompiler make output of library build indicates addition of "gcov" related options.
They have been put there as standard IDE options for building library.
I did NOT added these options.

make -j4 all 
Building file: ../MODULE/M_ARM_TEST/CARMTEST.cpp
Invoking: Cross G++ Compiler
arm-linux-gnueabihf-g++ -O0 -g3 -p -pg -ftest-coverage -fprofile-arcs -Wall -c -fmessage-length=0 -v -MMD -MP -MF"MODULE/M_ARM_TEST/CARMTEST.d" -MT"MODULE/M_ARM_TEST/CARMTEST.o" -o "MODULE/M_ARM_TEST/CARMTEST.o" "../MODULE/M_ARM_TEST/CARMTEST.cpp"
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-g++

The attached partial output of main program posts the "gcov" errors.

lRPI_BT_LIB_ARM -lbluetooth
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/libRPI_BT_LIB_ARM.a(CARMTEST.o): In function `_GLOBAL__sub_I_65535_0__ZNSt10C_ARM_TESTC2Ev':
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/../MODULE/M_ARM_TEST/CARMTEST.cpp:42: undefined reference to `__gcov_init'
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/libRPI_BT_LIB_ARM.a(CARMTEST.o):(.data+0x28): undefined reference to `__gcov_merge_add'
collect2: error: ld returned 1 exit status

NOTE The library source code line #42 is where error is actually indicated in output , at the closing bracket of "std" namespace comment

NOTE 42 } /* namespace std */

1. What is the purpose of having -ftest-coverage -fprofile-arcs option SPECIFICALLY for library? I do not have them in any other IDE build programs.
I did not try to delete them, perhaps after I have some more knowledge about their purpose.
2. I did try to add -lgcov to program linker but it did not work.
I understand that gcov is some kind of utility tracking application and not sure why I need it.

Any help woudl be appreciated.
Cheers

Re: gcov linker errors

Richard MacCutchan30-Jan-20 9:15