|
hi,
well the problem i am facing is that i have a class say A..which has the following declaration
class A: public CFontDialog
{
....
}
now in the initinstance of the dialog i want to get the resource id of dialog.
Can anyone please help me on the issue!
PS. i have tried GetWindowLong( GWL_ID )... but it returns 0. ......
please help.
lid.
|
|
|
|
|
|
well as i told earlier... i have this class manually defined and not defined against a dialog resource.... the member A::IDD you mentioned is defined by the new dlg wizard and is not present in case of CCustomDialogs more specifically CFontDialog ... so if you have anything else in mind. please update me..
thankx for the time and consideration.
lid
|
|
|
|
|
otherwise, you can have the hWnd pointer with :
CFontDialog fontDlg();
CWnd pWnd = fontDlg->m_hWnd;
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Hi
It might be in the CDialog::m_lpszTemplateName parameter.
HTH
Martin
|
|
|
|
|
Hi,
i have checked the m_lpszTemplateName parameter but its value is NULL..... anything else..???
please
|
|
|
|
|
Hi
What are you trying to do here?
The Dialog Resource is only used to create the dialog and once the dialog is running it's not accessed again - the same principle (barring contrived cases) applies to any dialog created from a resource template.
If you're trying to override the Font Dialog's default resource layout with your own, set the CFontDialog's m_cf.lpTemplateName data member to your adapted version of the standard Choose Font resource and work from there.
Martin
|
|
|
|
|
Hi,
This is almost exactly what i m trying to do over here... i have added my custom controls to the standard font dialog....? the problem is that when the windows DPI is changed to 120 some of the controls starts overlapping or the text is just bigger than the size of the control....i have found a code on code project which when provided the ID of the dialog makes all the controls of the dialog bigger according to the current DPI.
So, i was hoping to get the resource of the dialog somewho and pass it to the code downloaded from code project.....
BTW if the idea is silly  and is not workable... do tell me ...so i could search for some other solution.
lid
|
|
|
|
|
Hello there,
How do I change the window style of Internet Explorer. I placed the browser control on a Dialog. When the page pops up the browser control gets 3d style. I want to change the style to flat. How do I do this??
vyjesh
|
|
|
|
|
Hello Friends,
Please tell me what is meant by Call back function. How it works and an example?
Thanks in advance.
Neelesh K J Jain.
|
|
|
|
|
Hi Neelesh,
A CallBack function is called by Operating system. The classic example of a callback function is WndProc() function in "Hello World" sample found in any Win32 Programming book.
Regards
Abhi Lahare
|
|
|
|
|
1. you have two functions : FunctionA and FunctionB.
2. you call FunctionA with a pointer to FunctionB.
3. FunctionA calls FunctionB as part of its processing, usually in a loop.
Software | Cleek
|
|
|
|
|
...Additionally callback functions can be very useful in event notification purposes.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
#pragma pack(push|pop)
From what I remember...the last time I read up on what this pragma does was long time. 
Anyways...my understanding is that it forces a even byte alignment of structures, it's mebers, etc.
I've seen it used often in a structure and like I said...my understanding is that it causes data members to fall on quad byte boundries or whatever...for faster access times...
I think it's a CPU quirk that data accessed on an even 4 byte boundry is more efficient on 32 bit processers???
Sp my question is this...assuming I am correct in my above thinking...
Would it make a logical difference if I were to remove pragma's like this??? I find them annoying...and despite making code more efficient I'm not sure I think it's worth the harder to read code (I like things easy).
If this is the case...one more question:
The pragma surrounds structs which are then used in a MFC CArray...to holds potentially 1000's of elements...
So does this pragma make sure each of those elements will be accessed on an even byte boundry???
Or I guess...would it atleast make sure the first struct item in array was on an even byte boundry, so the rest that followed???
One more question: 
If a struct was 5 bytes would this pragma actually allocate 8 bytes for a single element, in this case using more memory in the trade off of speed in access times???
so 2 elements would actually consume 16 bytes instead of 10? wasting 3 bytes, but causing each to fall on even byte boundries???
Just curious...hope i'm on the right track here 
Thanks in advance
It's frustrating being a genius and living the life of a moron!!!
|
|
|
|
|
Hi
I agree with your concern about unnecessarily optimizing the runtime memory layout of C++ entities, and that byte-alignment in this case should enjoy less limelight than more important issues of software development.
However, I've had the need to use the packing pragma - typically in scenarios where I'm overlaying a C++ struct on a data byte array. For example, receiving a packet over the network - it's packed tightly by another program that is not necessarily concerned with extra byte-padding - and overlaying a C++ struct on top of that in order to interpret the elements contained in the data. Another example would be reading byte streams from a file.
Unless you're responsible for both consumer and provider of such byte sources, you'll have to be careful that the not-so-obvious extra padding of default byte-alignment doesn't cause problems (getting byte streams and C++ struct members out of sync) - because they are very tricky to find.
HTH
Martin
|
|
|
|
|
Yes that is example when pragma pack's are needed. I need them when I'm reading some structure from disk file. If i would not pack it, variables in the structure would have 'byte gaps' between themselves, and structure would be read incorrectly.
|
|
|
|
|
its typically used to 'pack' a structure into a certain byte alignment because otherwise the structure gets padded out automatically and things either use up more memory than necessary OR saving and loading mechanisms (particularly on cross platform code or tool development (e.g. 16 bit machines etc.)) end up reading in the wrong amount of data and so the struct it loads is full of rubbish.
However, my experience with #pragma pack is that its the most idiotic compiler directive i have seen. You can specify a struct with size 16 bits (using bit fields of type 'unsigned') specify a #pragma pack directive of 2 bytes (so the size of the struct should be 2 bytes in memory) and yet it fails badly and instead aligns it on a 4 byte boundary ! ! Change the unsigned type to unsigned short and it chucks it on a 2 byte boundary, hooray ! !
My verdict :
Its absolute rubbish.
"When I left you I was but the learner, now I am the master" - Darth Vader
|
|
|
|
|
"I think it's a CPU quirk that data accessed on an even 4 byte boundry is more efficient on 32 bit processers???"
That's correct and the P4 is really horrendous at it. P3s and AMD processors have an easier time of it.
Actually, the default packing of data structures is to the size of the item ie., doubles are aligned to the nearest eight-byte boundary, ints on a four-byte boundary, and shorts on a two-byte boundary.
From MSDN : "If you use #pragma pack without an argument, structure members are packed to the value specified by /Zp. The default /Zp packing size is /Zp8."
I do a lot of work with communications in various manners and we often use pack(1) insure that the data that we transfer is aligned correctly. If the processor has difficulties with that then we just have to deal with it.
|
|
|
|
|
Hi,everyone:
i access my data of Doc using following code:
<br />
CMainFrame* pMainFrmWnd = (CMainFrame*)AfxGetMainWnd(); <br />
ASSERT(pMainFrmWnd != NULL); <br />
<br />
CWnd* pchildWnd = pMainFrmWnd->GetWindow(GW_CHILD);<br />
ASSERT(pchildWnd->GetSafeHwnd() != NULL);<br />
<br />
CvcydcjView *pMyView = NULL; <br />
while(pchildWnd->GetSafeHwnd() != NULL)<br />
{<br />
ASSERT(pchildWnd->GetSafeHwnd() != NULL);<br />
if(pchildWnd->GetRuntimeClass()->m_lpszClassName == "CvcydcjView")<br />
{<br />
pMyView = (CvcydcjView*)pchildWnd;<br />
break;<br />
}<br />
pchildWnd = pchildWnd->GetWindow(GW_HWNDNEXT);<br />
}<br />
ASSERT(pMyView != NULL);<br />
<br />
CvcydcjDoc *pMydoc;<br />
pMydoc=pMyView->GetDocument();<br />
ASSERT(pMydoc != NULL);<br />
<br />
pMydoc->MyData="demo";<br />
but when i use it in a thread, it didn't work, it seems stopped at
pMydoc=pMyView->GetDocument();<br />
can you give me some suggestions? Thx!
- - - - - - - - - - - - - - - - - - - - - - - - - -
Many nights we prayed with no proof anyone could hear, we were moving moutains long before we knew we could !
Yet now i'm standing here, although we know there's much to fear, hope seems like summer bird too swiftly flown away ...
There can be miracles! When you believe, though hope is frail, it's hard to kill !
Who knows what miracles, you can achieve! When you believe, somehow you will ...
YOU WILL WHEN YOU BELIEVE
|
|
|
|
|
I don't have the answer to your question but a little suggestion. When you create your thread, why don't you pass the document (through the use of the LPVOID pParam) to the thread function and then use it there ?
|
|
|
|
|
Thank you for your suggestion.
i create the thread in my view class with following code:
<br />
m_hCallthread = CreateThread(<br />
NULL,
NULL,
CallOut,
NULL,
0,
NULL
);<br />
could you tell me how to pass the pointer? thx? i try replace last NULL with this, it didn't work. 
sorry, i'm a new bie of vc... wait for your answer... Thank you very much!
- - - - - - - - - - - - - - - - - - - - - - - - - -
Many nights we prayed with no proof anyone could hear, we were moving moutains long before we knew we could !
Yet now i'm standing here, although we know there's much to fear, hope seems like summer bird too swiftly flown away ...
There can be miracles! When you believe, though hope is frail, it's hard to kill !
Who knows what miracles, you can achieve! When you believe, somehow you will ...
YOU WILL WHEN YOU BELIEVE
|
|
|
|
|
Create your thread like that (supposed you have a pointer to your document that is called pDoc):
m_hCallthread = CreateThread(<br />
NULL,
NULL,
CallOut,
pDoc,
0,
NULL
);<br />
Then in your thread function you'll need to cast your void pointer to your document again:
CYourDoc* pDocument = (CYourDoc*)pParam;
|
|
|
|
|
Thank you very much! It works 
- - - - - - - - - - - - - - - - - - - - - - - - - -
Many nights we prayed with no proof anyone could hear, we were moving moutains long before we knew we could !
Yet now i'm standing here, although we know there's much to fear, hope seems like summer bird too swiftly flown away ...
There can be miracles! When you believe, though hope is frail, it's hard to kill !
Who knows what miracles, you can achieve! When you believe, somehow you will ...
YOU WILL WHEN YOU BELIEVE
|
|
|
|
|
Dick.leeSolucky wrote:
can you give me some suggestions?
Using MFC documents/windows in a thread is not recommended. In fact, most of the time it simply won't work. You'll have to pass a pointer to your data to your thread routine.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thank you for your reply.
we need have a thread dealing with something(like initialize drives,and connect to voice_board and dial ...) and our main functions are all in View class, for example: displaymessage... we store the data in doc class.
may i create the thread in my doc class or view class? then i can access the data easiler, but it seems if we create the callout function in view class,we get these errors:
<br />
D:\VC YDCJ\vcydcjView.cpp(431) : error C2664: 'CreateThread' : cannot convert parameter 3 from 'int (void)' to 'unsigned long (__stdcall *)(void *)'<br />
None of the functions with this name in scope match the target type<br />
thank you and waiting for your reply... thx!
- - - - - - - - - - - - - - - - - - - - - - - - - -
Many nights we prayed with no proof anyone could hear, we were moving moutains long before we knew we could !
Yet now i'm standing here, although we know there's much to fear, hope seems like summer bird too swiftly flown away ...
There can be miracles! When you believe, though hope is frail, it's hard to kill !
Who knows what miracles, you can achieve! When you believe, somehow you will ...
YOU WILL WHEN YOU BELIEVE
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
