|
Here are the resource statements Here is the call The resource in question is IDC_CUSTOM5 Fail means that when I comment out that CONTROL staement tracing my code the create goes to my
OnInitDialog my question is in the class parm of the resource control can it be my own class which I register at run time via RegesterClass
thank you
BOOL ret2 = drivestorage->Create(IDD_DIALOG10, m_pMainWnd);
IDD_DIALOG10 DIALOGEX 0, 0, 769, 429
STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Storage View / Change"
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
CTEXT "",IDC_TCB,45,30,47,8
CTEXT "OwnIng TCB",IDC_STATIC,41,13,58,8
CTEXT "",IDC_SP,164,28,43,8
CTEXT "Storage SubPool",IDC_STATIC,162,12,55,8
CTEXT "",IDC_ASID,265,26,32,8
CTEXT "Asid",IDC_STATIC,269,9,31,8
CTEXT "",IDC_FP,399,31,19,8
CTEXT "Fetch Protect Key",IDC_STATIC,392,15,63,8
CONTROL "",IDC_CUSTOM5,"PieCOntrol",WS_TABSTOP,617,99,109,109
COMBOBOX IDC_COMBO1,491,236,48,30,CBS_DROPDOWN | CBS_SORT | WS_VSCROLL | WS_TABSTOP
CONTROL "",IDC_EDIT2,"RichEdit20A",ES_MULTILINE | WS_BORDER | WS_TABSTOP, 45,106,494,314
EDITTEXT IDC_EDIT1,45,110,494,314,ES_AUTOHSCROLL
COMBOBOX IDC_COMBO2,637,244,67,16,CBS_DROPDOWN | CBS_SORT | WS_VSCROLL | WS_TABSTOP
LISTBOX IDC_LIST2,641,310,68,11,LBS_SORT | LBS_NOINTEGRALHEIGHT | WS_VSCROLL | WS_TABSTOP
END
|
|
|
|
|
ForNow wrote: can it be my own class which I register at run time via RegesterClass I am not sure as I have never tried that. The documentation at CONTROL control - Win32 apps | Microsoft Docs[^] states (although it is slightly ambiguous) that it must be one of the predefined classes. If your code is failing when you try it with a locally defined class then you need to use the debugger to find out why.
|
|
|
|
|
I think the documentation means you have to Register the Class before calling CDialog::Create as I remember I forgot to call AfxInitRichEdit before doing a CDialog::Create and it failed I think CDialog::Create Checks Uid template dialog resource and sees if the classes are registered
Thanks you
|
|
|
|
|
I assumed you were doing that anyway, since Windows cannot create an object of a class that it does not know about.
|
|
|
|
|
I've never tried it so I'm not sure exactly how it works but I notice a rather strange capitalization in you class name: "PieCOntrol" . I don't know if Windows is case sensitive or not when looking for class name.
Mircea
|
|
|
|
|
Thanks that’s they way I had it in my wndclass I am displaying a pie chart on the side of a dialog box but need a Cwnd class to hang it off of thats the class I’m using for it used the cpiedemo from this site for learning
|
|
|
|
|
|
|
|
Hi,now I need to sign pdf and verify the signatue of a signed pdf,could someone tell me is there any C++ library can do this.
|
|
|
|
|
|
Im getting a stack over flow execption its not from an ASSERT but storage on my stack frame is corrupted. I have a thread Waitting on event to be notified when a socket read is pending
I trace socket number upon entry and its ok I initialize a WSABUF which 15 entires and its fine somewhere when I do the WaitforSingleObject the stack frame gets corrupted
I did a data break point on the socket and its was somewhere in UserCallwinprocccheckwow.
best to post my code some where in the WaiforSingleObject sonething happens to my stack frame
here is the code for notification
int ret1 = WSAEventSelect(mysocket, socksevent, FD_READ | FD_CLOSE);
here is the createthread
struct threadparm thethreads;
thethreads.thesocket = mysocket;
thethreads.sendwidow = pFrame->m_hWnd;
thethreads.messge = WM_STORAGE;
thethreads.sockevent = socksevent;
struct threadparm* parmptr = &thethreads;
HANDLE threadhandle = ::CreateThread(NULL, 0, SocketThread, (LPVOID)parmptr, 0, &threadid);
the thread with Waitforsingleobect were somewhere threadptr->thesocket gets corrupted
DWORD WINAPI SocketThread(LPVOID lphadleparater)
{
WSANETWORKEVENTS socknetwork;
struct threadparm* threadptr;
threadptr = (threadparm *)lphadleparater;
WSABUF DataBuf[15];
DWORD recived;
int i, j;
DWORD flags = 0;
WSAOVERLAPPED myoverlap;
char* sendcopy = new char[3825];
char* holdptr = sendcopy;
j = 0;
for (i = 0; i < 15; i++)
{
DataBuf[i].buf = new char[255];
DataBuf[i].len = 255;
}
struct _WSABUF* tcpip = &DataBuf[0];
DWORD dwWaitStatus = WaitForSingleObject(threadptr->sockevent, INFINITE);
switch (dwWaitStatus)
case WAIT_OBJECT_0 + 0:
{
int return_code = WSAEnumNetworkEvents(threadptr->thesocket, threadptr->sockevent, &socknetwork);
|
|
|
|
|
It would be easier to look at your code if it was formatted. However, it isn't obvious to me what's causing your stack overflow. Do you have more code that you're not showing?
A stack overflow is caused by too much function call nesting (perhaps because of recursion), too many local variables (usually large arrays), or creating a thread with a smaller stack than it needs (that's the second parameter to CreateThread , and since you're using 0 , you're getting Windows' default size, which should be OK).
|
|
|
|
|
is there a way to determine how much storage my local variables are currently taking maybe an output on the build
thanks
|
|
|
|
|
If there's a compiler option to generate a listing file, that might contain the information. I've never done this in Windows C++, so you'd have to look into it.
Another way would be to do this at the top of your function:
int first;
int last;
int size = &last - &first; if(size < 0) size = -size; size -= sizeof(int);
cout << "This function's locals use " << size << " bytes." << std::endl;
|
|
|
|
|
|
This might not work - the compiler doesn't have to maintain the order of variables on the stack, so last could end up before or after first and the other variables.
|
|
|
|
|
Seems to me the thethreads was allocated on the stack and disappeared by the time thread is executing.
As Greg was saying, formatting would be nice.
Mircea
|
|
|
|
|
you are right about the formatting thethreads is in the stackframe of CWinApp but still you are correct in your point I'll move its thehreads to the class
thank you
|
|
|
|
|
What`s a function in ASM? My guess is that it`s an isolated sentence sequence that gets an ID. When the sequence is called from another sequence, the location in the original sequence where the calling is taking place is saved in the sequence being called (as some kind of statement that is placed at the end), the execution of the initial sequence is paused and the traversal/iteration through the sequence being called is started, when the execution reaches the last statement, that last statement contains the saved location of the place where the sequence was called from and is used to resume the execution in the first/initial sequence.
|
|
|
|
|
Your guess is mostly right.
For a real life assembly example, see, for instance: 8051 CALL INSTRUCTIONS[^].
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Thanks CPallini, a confirmation/denial is what I was looking for.
|
|
|
|
|
You are welcome.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
As CPallini writes: Essentially correct.
But your description is so abstract that it applies as well to functions in any algorithmic language, from Fortran through Algol and Pascal and C and C#. It is certainly not ASM specific.
Actually, I'd say: Quite to the contrary ... If your title line hadn't said 'function translated to ASM'. If you hand code ASM, you have a lot more freedom. E.g. that 'sentence sequence' would not have to be that isolated: A function could have multiple entry points. (For an extreme case: Read Jumping into the middle of an instruction ...[^]).
Also, I think that parameter transfer and return of result value(s) is such an essential part of the function concept that it should be included in even the most basic definition/description of the function concept. But again, parameters are certainly not specific to ASM functions; it applies equally to ASM and high level languages.
Rant part:
I really wish that you were right about 'an isolated sentence sequence that gets an ID'. That is not the case neither in ASM nor in C style languages. The ID does not identify the sentence sequence, but the point in the code at the start of the sequence. This is one of the major fundamental flaws in the design of these languages.
In a few other algorithmic languages, such as CHILL, a label identifies a sentence sequence, that be a function, a loop, a conditional statement or whatever. Usually, a sentence sequence is termed a 'block'. You can e.g. break out of any block by stating its ID, even if it is not the innermost one. You can have compiler support for block completion by repeating the block ID at the end, improving readability a lot and catching nesting errors.
If there were a dotNET CHILL compiler out there, I'd gladly kick out C# (even if C# certainly is my favorite alternative in the C class of languages)!
|
|
|
|
|
In ASM there is no distinction between functions and procedures. The name procedure is usually used. You can only CALL a procedure. A function in the high-level sense (a procedure that returns something) is just a variant.
Regarding passing parameters to procedures in ASM. This can be done:
a) By putting values to CPU registers. This works if the number of parameters is small and parameters are rather simple data types. The procedure has direct access to parameters by means of registers. Compilers do this for simple functions/procedures/methods. Of course you need to save registers to stack and restore them after return. This is named the call sequence/frame of the procedure.
b) By pushing parameters to the stack. This is the facto standard. You can push parameters from left to right (the so-called "Pascal" convention) or from right to left (the so-called "C" convention). The "C" convention works also with procedures that have a variable number of parameters. This is why the C function printf has the format as the first (and mandatory) parameter - it will be on the top of the stack when entering printf and printf will know where to find it (the format is supposed to correctly describe the number ad type of each other parameters like %s, %d etc.)
When returning from the procedure the stack must be discarded of the parameters that were put on the stack. This can be done by the caller (the "C" approach) or by the procedure (the "Pascal" approach).
E.g. "ADD SP, 24" or "RET 24". The c/C++ compilers use of course the "C" approach.
Observe that the caller "knows" exactly how many parameters were pushed onto the stack so discarding the stack by the caller is more natural. Windows SDK uses "Pascal" convention.
When dealing with large objects that must be passed, it's easier to pass then by reference, i.e. to pass an address (pointer) to a memory area where the object is stored. A pointer is a simple type.
If you really need to pass a large object by value (i.e. make a copy), you can copy the internal representation of the object onto the stack, and define the stack frame so that procedure has access to it. However this is more time-consuming.
b) Combinations of the above 2 methods.
A procedure can return a value (i.e. becoming a function) by:
1) A register (if the return value is a scalar type). For Intel CPU, the convention is to return in the accumulator (AL, AX, DX:AX, EAX, etc., depending on the processor type). Observe that scalar types include all numerical values (int, float, double) and pointers.
2) If the result is a large object, things get complicated, because when converting "return t" into machine code, a copy needs to be done somewhere in memory. However compilers can do whatever they want, assuming they don't break the language semantics. A copy could be made onto the stack.
That's why is best to avoid methods that return objects in C++/C# etc. Pass a reference/pointer where you want the result to be placed instead.
See for example: <a href="https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization">
If you work directly in ASM and are not just interested in interfacing high-level language with ASM-level modules, you can use any combination of the above methods. For example, pass the first parameter by means of a register and the rest onto the stack (there are compilers that do that).
However, I recommend to stick to conventional methods. You never know when you will need to call an ASM procedure from C++ or a C++ method/function from ASM.
In any case, any compiler documents (or should document) very exactly how it transfers parameter to procedures, and hw results are returned by functions. If you need to work at this level, read this carefully, and then make a small interface project. What I described above is merely a top-level sketch.
Unfortunately, ASM is not so much taught in universities nowadays (more just as an addendum to digital electronics) and this is really a pity. Many questions regarding pointers, references, memory allocation, constructors, destructors etc. would become more clear and even obvious to developers if they had a small ASM experience.
|
|
|
|
|