|
|
If it clears things up at all....
If you ever write some C++ code using MFC (Microsoft's Foundation Class, essentially an OO wrapper around the WinAPI), you'll notice that there are always initialization routines aside from constructors (they're called OnInit...blah ).
If you happen to use a dialog object, and attempt to draw from the constructor instead of the initialization routine, you'll notice that the objects exist but are not windows yet so you'll get an assertion (if running in debug mode). This means that the constructors have been called but nothing has been drawn yet. The drawing only occurs after all the constructors have been called, the initialization routines are systematically called after that and you can load all the widgets with whatever the default values to be displayed are.
Moral of the story, drawing typically doesn't take place during construction of objects.
|
|
|
|
|
Hi,java has
-- modified 3-Apr-18 8:53am.
|
|
|
|
|
madhuresh sachan wrote: after this line cursor goes direct to the end of function,does not read below given code
What does this mean?
How did you know that the code is not read (executed would be a better word) if not using the debugger?
Your code snippet contains no operation that changes any GUI element (enables/disables items) so that you would not 'see' anything.
So run your program in the debugger and check what happens (e.g. by inspecting pRibbon, initial pos, lstItems.GetCount(), and the loop execution).
|
|
|
|
|
Thanks for your reply
pRibbon->GetItemIDsList(lstItems);
In "lstItems" all the items of menu is coming,
But the Main Problem is
when I run this on debug mode,it is not executing the code after "pRibbon->GetItemIDsList(lstItems);" line of code.
|
|
|
|
|
So when you set a breakpoint at the for loop after
pos = lstItems.GetHeadPosition();
that is not hit and execution is not stopped?
That would be weird.
I assume that you are using a debug build with all optimisations disabled. Otherwise, the compiler may optimise away the following lines because they effectively do nothing.
To check this you can insert a TRACE statement inside the loop printing nElement.
|
|
|
|
|
I was asked, "If we have mutexes, why do we need critical sections?"
My answer was that mutexes protect resources and critical sections protect code.
Was I on the right track?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote:
Was I on the right track?
You decide:
Critical Section vs. Mutex - MSDN Blogs[^]
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I would think that in general, mutexes are purely kernel controlled objects whereas critical sections are mostly "user mode primitives", meaning it's application level logic most of the time (which runs a lot faster without requiring the kernel to be involved). Of course, this also implies a critical section is bound within a process and cannot be shared across processes. The exception is when there actually is a conflict, then a critical section makes a kernel call for synchronization.
If you write some test code, you should be able to notice the speed advantage of a critical section (and all the kernel system calls of a mutex).
|
|
|
|
|
Been working on Matt Pietrek's code from an old Microsoft Systems Journal article he wrote about eliminating the C Runtime (LIBC or LIBCMT) from my C++ executables, i.e., using the linker /NODEFAULTLIB switch. Your own Mike_V
wrote a tutorial on that here too...
http://www.codeproject.com/Articles/15156/Tiny-C-Runtime-Library
Everything's working GREAT for me with it except for one point which really has me scratching my head. I can't figure out how to convert a floating point number to its string representation without using one of the printf family functions in the C Runtime. Of course, Win32 'covers' or has its own versions of some of these functions, e.g., wvsprintf in user32.lib has a format specifier parameter, but its not complete; it has everything but %f, which we need to convert a floating point number to a string buffer (try it and you'll see - it doesn't work). And I obviously can't use the C Runtime functions if I'm trying to eliminate them! Does anyone know of a Win32 function which can be used to convert a floating point number into a provided character string buffer??? On MSDN I found a whole bunch of odd named functions I'm totally unfamiliar with...
StringCchLength
StringCchPrintf_l
StringCchPrintf_lEx
StringCchPrintf
StringCchPrintfEx
StringCchVPrintf_l
StringCchVPrintf_lEx
StringCchVPrintf
StringCchVPrintfEx
...and was wondering if anyone knows if any of these or perhaps some other exists which would solve my problem?
|
|
|
|
|
Shoot! I think I got it! Tried the 1st on my list above, i.e., StringCchPrintf() and it did it. Its in StrSafe.lib. I hope to God that doesn't use the C Runtime or I'm back to square one! I'll let you all know!
Fred
|
|
|
|
|
Nope. Doesn't work. Unless someone can tell me different, here's the way I see it.
Even if I find a Windows specific function that will take as an input parameter a floating point number and output into a character buffer an asci or wide character rendering, I won't be able to use it against the /NODEFAULTLIB linker switch, because it'll just be a wrapper that calls one of the functions in the C Runtime. And it'll give me linker errors. That's what happened with StringCchPrintf().
So at this point, unless someone can tell me different, I see my only choices as these two...
1) Give up on any window/console/file output using floating point numbers without the C Runtime;
2) Write my own floating point package involving the fpu.
I guess I'll try option #2 above. I see at the masm32 site there is an fpu package with assembler source available. However, I hadn't mentioned, I'm really doing 64 bit and need that. So I've got my work cut out for me.
The reason I'm doing this is because I hate the bloat of modern software. Can't take it anymore. I like C++ OK but I won't use any C++ Std. Lib. code. I write all my own library code, string class, dynamic multidimensional arrays, whatever I need, etc. So now I guess I need to come up with my own floating point code. Please save me somebody! Tell me I'm wrong!
|
|
|
|
|
So you don't want to use the standard C library with your program.
Than you have to implement all necessary functionality provided by that library and required by your application yourself. The common method to do such things is to place such functions in a library to be re-used by other projects. As a result, you will have your own standard C library (or a sub set) when using the same function declarations (which makes sense). The LIBCTINY mentioned in your article link is such an implementation.
The StringCch... functions mentioned above are just MS specific extensions to the standard library providing safe and ANSI/Unicode operations. If you have a look at StrSafe.h where they are defined, you will notice that they use the standard C library functions. So you have to implement the used functions when not using the default library.
You may search further for some Windows API function that can perform a required operation. The FormatMessage function (Windows)[^] is a candidate but did not support floating point values. However, it allows passing a pre-formatted floating point argument as string. So it may be sufficient to have a function that converts a floating point number to a string.
As far as I know the Windows API did not provide such a function. I guess there is an internal / undocumented one. But that might not be available.
So the solution is to write your own. As starting point you may have a look at some C standard library source. Candidates are for example The GNU C Library[^] and diet libc - a libc optimized for small size[^].
Finally you should know that your program will use a special standard library version when calling Windows API functions because the OS contains it's own implementations of required functions.
|
|
|
|
|
Thanks for the thoughtful responses Jochen and Richard. Much appreciated.
Here's where I'm at. Just got Raymond Filiatreault's fpulib working for me from www.masm32.com. Its part of the masm32 install. Really nice. So next my intent is to write a C prototype for the function I need and either link against the *.obj or even the lib.
However, I'm some disappointed at this point. I was really hoping to solve my 64 bit bloat issues with all this, but Raymond Filiatreault's fpu lib is 32 bit.
By the way, it was easy to get Matt Pietrek's LibCTiny.lib working in x64; just a tweak here and there.
But while it would be satisfying to get all my stuff working in 32 bit, I really want 64 bit. Would either of you guys know of a 64 bit fpu lib available anywhere? As you mentioned Jochen, maybe I ought to check out the GCC sources.
As an aside, looking at Microsoft's printf.c and _output.c code gets into some pretty ugly stuff. There's an array of function pointers like so...
_cfltcvt
...and some other undocumented functions involved in the floating point conversions.
But I'm tickled at the size reductions I've achieved. A simple "Hello, World!" with my string class is around 70 k with VC 9 from VS 2008, /MT build. With the C++ Std. Lib's string class we're at around 92 k. With my String Class and LibCTiny plus a half dozen additions to it I had to make, I'm only at like 6 K!!!!!
|
|
|
|
|
I don't see the relation between 64 bit and basic floating point operations (regardless if implemented by emulation, FPU, or vector instructions) when using a C compiler.
Functions like _fcvt[^], ecvt, and gcvt are part of the standard library and usually call sprintf so that they are not helpful (at least the GLIBC does that).
|
|
|
|
|
[QUOTE]
I don't see the relation between 64 bit and basic floating point operations (regardless if implemented by emulation, FPU, or vector instructions) when using a C compiler.
[/QUOTE]
Well, perhaps I'm laboring under false knowledge. I have a 32 bit masm created FPU lib, i.e., fpulib.lib, which has within it the function I need, e.g., ...
FpuFLtoA(...)
...which returns through an out parameter my floating point number converted to a Z string. I can't link that 32 bit library into 64 bit code can I? I just assummed not, because of the fact 32 bit dlls can't be directly used by 64 bit binaries.
And thanks again for the information on those various functions deep in the internals of printf. I hadn't looked into that end of it deep enough to determine where they were implemented, but what you told me closes that possibility, apparently.
Where I'm at now is if I'm to use your links to download the GCC sources I apparently have to install and learn to use git. Years ago I worked with Linux some but never became terribly proficient in that world. Never could find anything comparable to the Windows Api for writing GUI apps. About the closest thing I could find that I could marginally tolerate was GTK. I liked XLib but it wasn't suitable for creating GUI apps (no controls (widgets). But unless you tell me I can link 32 bit libraries into 64 bit executables, or somehow I can come up with a 64 bit FPU lib (if I need it), I see studying the GCC sources as my only hope?
|
|
|
|
|
You can't off course link a 32-bit library to a 64-bit application. You have to build your own 64-bit library using a 64-bit assembler. But the assembly code should be quite identical (besides the register names / width) because the FPU commands does not depend on 32/64 bit.
Alternatively you can try to port the assembler code to C.
You can download the GLIBC sources also as tar ball: Index of /gnu/glibc[^] which can be extracted on Windows with 7-Zip[^].
But be aware that finding the code used by the printf functions to format floating point might took some time (there will be calls to other functions located in other files and various macros). Maybe diet libc - a libc optimized for small size[^] is an alternative option.
Note also that the above may use assembler code too.
A quick check with my GLIBC sources show that a starting point might be the file stdio-common/printf_fp.c.
|
|
|
|
|
Thanks Jochen! I'm making progress. Put in a brutal day yesterday and got that asm code working for me in both asm and VC9 C++. Lost some hide but finally got it to work. Here's some of my by now dried blood...
Uggh. Don't know how to do links here. 
What you said above about there not being much change in the fpu unit between the various processors makes sense and I'm heartened by it. It also says that in the fpu tutorials at masm32.com I have the asm source for the code that is doing what I need. Perhaps I could get myself a 64 bit assembler and reassemble it. But at this point I'm making progress and today hopefully will be able to incorporeate my newly working float routine into my string class code.
If I can't then I'll tackle the GCC sources. I appreciate your pointing me in that direction and providing the links and info.
|
|
|
|
|
Fine to heat that you got some kind of success.
To post a link just copy it to the clipboard, insert in the CP editor, and wait a short time. It will be inserted as link with the title of the page as pre-selected link text (so it can be edited).
|
|
|
|
|
Frederick J. Harris wrote: a Win32 function which can be used to convert a floating point number into a provided character string buffer
How would that help, since it will use the C runtime under the covers. If you do not wish to use the standard library then you will need to write your own function to do the work; and all the other pieces that would be needed. Remember, all string handling is done in the library, it's not part of the C language.
|
|
|
|
|
Good day. Please am writing an application, though things are going good. But am stucked in the area where l need to copy the text of what the user selected from a combo box and use that text to initialize the text field of the TC_ITEM struct to show on the tab control. l had tried many tactics. Code snippet below:
static WCHAR subject1tab[MAX_LOADSTRING];
INITCOMMONCONTROLSEX icce = {0};
TC_ITEM tie={0};
icce.dwICC=ICC_TAB_CLASSES;
icce.dwSize=sizeof(INITCOMMONCONTROLSEX);
InitCommonControlsEx(&icce);
tie.mask = TCIF_TEXT;
subjecthwnd=GetDlgItem(hwnd,IDC_UNICALPTUME_SUBJECT1);
GetWindowText(subjecthwnd,subject1tab,100);
tie.pszText=subject1tab;
SendMessage(SubjectTabs,TCM_INSERTITEM,(WPARAM)0,(LPARAM)&tie);
So please can someone help me on how to get the text string of selection from a combobox and use it to initialize a tab.
Thanks in advance.
modified 27-Jan-16 15:09pm.
|
|
|
|
|
|
@blingg: TC_ITEM is same as TCITEM but according to MSDN, TCITEM supercedes TC_ITEM.
However, l have done the corrections, still it doesn't work. l also used SendMessage, still yet no avail. l don't know what's wrong.
|
|
|
|
|
Set tie.iImage to -1 and make sure SubjectTab is a valid tab control HWND.
|
|
|
|
|
You first need to check that you are actually retrieving some text from your control. Is this code inside the dialog that holds the combobox? You also need to set the text length in your TCITEM before sending the TCM_INSERTITEM message.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
