|
Did you follow the link and read the comments from Microsoft?
Veni, vidi, abiit domum
|
|
|
|
|
Do not know how but I understood 
i am commented some code in files: atlapp.h and atlgdi.h
|
|
|
|
|
Hi,
I am using MSXML parser. I need to handle exceptions for load xml file , parse it etc.
Cam anyone plz give me some reference for this?
Thanks
|
|
|
|
|
sma123# wrote: Cam anyone plz give me some reference for this?
Reference for what exactly? Exception handling is the same whatever your code is doing.
Veni, vidi, abiit domum
|
|
|
|
|
Windows 7, Visual Studio 2008, C++, not managed code
So far, it seems that the best way to start a thread is with this:
uintptr_t _beginthreadex(
void *security,
unsigned stack_size,
unsigned ( __stdcall *start_address )( void * ),
void *arglist,
unsigned initflag,
unsigned *thrdaddr
);
found here: http://msdn.microsoft.com/en-us/library/kdzttdcb(v=vs.90).aspx[^]
I found the article in CodeProject about starting a class as the thread and am using that.
The one argument to the thread is the address of a structure used to pass data between the main app and the thread. Call it common_structure. The method that will be started is Main_TCP_Class( void * common_struct ){...} (This class will handle my TCP/IP work and that thread will run for the duration so it seems Main_TCP_Class() is an aptly descriptive name.)
Question: Does the act of starting the thread with _beginthreadex(...) instantiate the class? If not, there will be some follow up questions on this.
If so, that would mean, I presume, that the constructor runs before method Main_TCP_Class() runs. And that means that none of the data in common_structure is accessible until Main_TCP_Class has started and has captured the pointer in the argument.
Is this correct? Any pitfalls that I should be aware of?
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
bkelly13 wrote: Does the act of starting the thread with _beginthreadex(...) instantiate the class?
No, it merely starts the thread at the address pointed to by start_address. You may be better using the CreateThread[^] call, which is more closely integrated to the Win32 API. Neither _beginthreadex nor CreateThread have any knowledge of the structure of your program, in terms of classes and other structures.
Veni, vidi, abiit domum
|
|
|
|
|
RE: No, it merely starts the thread at the address pointed to by start_address.
That makes sense, the class must be instantiated before passing in the one method to CreateThread().
But, since the main app has created the class and has its address, what prohibits the main app from calling methods in the class? Yes, I am mostly aware of problems that may cause. My intent is to call methods such as:
Set_Logging_Flag( bool new_value );
bool Get_Logging_Flag();
These methods would just set flags that the thread would detect then act upon.
Note that I wrote "mostly aware of" as I am certain there are things of which I am not aware.
Edit shortly later:
Following the codeproject article resulted in the following in the dot H file:
void Main_TCP_Class( void * common_structure );
static unsigned __stdcall ThreadStaticEntryPoint( void * pThis )
{
C_Server_TCP_Win_Api * p_C_Server_TCP_Win_Api = (C_Server_TCP_Win_Api * )pThis;
p_C_Server_TCP_Win_Api->Main_TCP_Class( m_common_data );
return 1;
...
static st_server_tcp_common_structure *m_common_data;
}
The compile failed until I declared the common structure static. OK. But one of the goals was to pass one argument to the thread and that argument could be a structure through which the main app communicates with the thread.
Possible Revelation: Since we declare that structure as static, and the main app instantiates the class before starting it as a thread, it has access to that static class regardless of how the class is run. So why go through all this to pass the argument?
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
modified 26-Nov-13 16:32pm.
|
|
|
|
|
bkelly13 wrote: what prohibits the main app from calling methods in the class?
Nothing at all, but those methods will be running in a different thread so will have no effect on the thread that you previously started. Threads communicate by using common areas of memory, and they must each synchronise their actions so they don't corrupt the space.
bkelly13 wrote: Following the codeproject article
Questions about articles are best posted in the forum at the end of the article; the author is the best person to answer questions on the structure of their code.
Veni, vidi, abiit domum
|
|
|
|
|
Hello,
I have a point of confusion here. In response to my question you wrote:
Quote: No, it merely starts the thread at the address pointed to by start_address.
I concluded that CreateThread would not create an instance of the class, just start it running as a separate thread. From that I conclude I must instantiate the class then start it as a separate thread. If that is so then calls to that class would be in the same address space. If not, then why would I instantiate it before calling CreateThread?
In either case I don't know what will happen.
I had some difficulties with the code I was writing so I stripped it down to the bare bones of nothing more that being able to start a thread. I will be working with that in the meantime.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
As you say, CreateThread would not create an instance of the class. This function creates a new process which runs in parallel with the currently running code, starting at the address given. Within the new process you can create new objects of a class and run their methods, while other objects are actioned in the main thread. As I said before, there is no communication between the two processes except by passing information through shared memory. You may find it easier to run your separate thread as pure procedural code rather than as classes. But that will, of course, depend on what the code is actually doing.
Veni, vidi, abiit domum
|
|
|
|
|
Hello,
Re: Quote: You may find it easier to run your separate thread as pure procedural code rather than as classes. But that will, of course, depend on what the code is actually doing.
I have been thinking about that quite a bit. It would probably be easier to start the process as a single procedure not wrapped up in a class. But, this is for TCP/IP and there is quite a lot to do. I suppose everything could be free standing functions, but that would require a single monster procedure or require a flock of arguments for every call.
Being a single person software team where I work has some advantages, but they are truly overwhelmed by the disadvantage of not having anyone to discuss ideas with.
I think I will go to a single simple function to test out the concepts and try to get some events working. Then I will return to the TCP/IP part of this. Working one problem area at a time will make this easier.
Thank you for your thoughts.
EDIT: I have worked this on and off through the day. The current status is that creating a simple thread with some events using a free standing procedure is easier than I thought and easier that it looks. Putting a TCP/IP manager in a single procedure would probably get ugly. Right now my next step is to see what it takes to put this one procedure in a class and start it as a thread.
Would this be worth writing up as a series of articles? Article 1: Simple thread, 2: Thread from a class, 3: TCP/IP as a separate thread.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
modified 28-Nov-13 23:21pm.
|
|
|
|
|
If you find it helpful, odds are somebody else will as well. With that said, there are a ton of threading and tcp/ip articles, so browse through them to make sure you're not just rewriting an article that's already been written.
When you say: "thread from a class", what do you mean? There is an MFC class called CWinThread that allows you to make an entire class that is it's own thread, including the messaging pump required to communicate with it without a separate mutex/critical section (although usually you end up using a combination of messaging and mutexes anyway).
|
|
|
|
|
I used the phrase of start a thread from a class to indicate that a particular class, such as a TCP/IP manager class, be started as a separate thread from the main app. It turns out there are some difficulties and while relatively simple to execute, I find the code difficult to read. In particular the solutions I found have a difficult to fathom pointer cast and must have a static function used to fire it off.
HOWEVER: I just discovered a way to completely bypass that problem. Begin with the class, which of course has a single method, call it main_method() that will loop as needed and not exit until the purpose is complete. Then write a simple free standing procedure. All that procedure does is instantiate the class then call main_method(). It takes one line to instantiate the class and one to call the method. When the method returns, the next line of code deletes the class and one more calls _endthreadex() to formally end the thread. That is really trivial but none of the articles I read about present this concept. (And yes, this completely ignores communications between the thread and the main app, but that is also not so difficult.)
Does anyone know of any disadvantage to this?
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
There are some simple issues with using _endthreadex() and in a typical worker thread you don't even have to call it explicitly but in any case... I don't quite see why doing all this is beneficial. Maybe if you posted some of the code for reference I could give you some better feedback.
|
|
|
|
|
My application is to process telemetry data and send it to a display device. The band width is high so the TCP/IP manager will be in a separate thread. To my knowledge I have this figured out now. The function that instantiates the class and calls it also calls endthreadex() when the class exits. Quite simple now.
But if you say there are issues with using _endthreadex() I would like to hear about them.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
Well if anything is waiting on the thread handle, it's going to wait forever (or until it times out) because the thread handle doesn't get dealt with properly, but that would only be an issue if you were waiting on the handle (or if another unsuspecting programmer waits on your thread handle).
Typically the proper way of ending a thread is to have it end itself. In the case of a socket handling thread, you can have something to signal an end to the capturing process. If your thread is in a blocking recv() call, closing your socket will trigger a return.
From MSDN:
Quote: Like the Win32 ExitThread API, _endthreadex does not close the thread handle.
|
|
|
|
|
I have a file tree.I want to showing "+" allways,no matter current node has child node.In my initialization，i do this:
TV_INSERTSTRUCT tvinsert;
tvinsert.hParent = item;
tvinsert.hInsertAfter = TVI_LAST;
tvinsert.item.mask = TVIF_TEXT|TVIF_CHILDREN;
tvinsert.item.cChildren=1;
tvinsert.item.pszText = (LPWSTR)(wstrFileName.c_str());
CTreeItem tmpItem = m_OrginazitionTree.InsertItem(&tvinsert);
And then it run. But I find a trouble,if current node don't hava child node,When I click it the current node "+" don't disappear.I want when the app initialization all node has "+" no matter node has child node,when I click one of tree node,if current node don't have child node,then this current node "+" will disappear.But this trouble I can't fix it.Is someone can help me ?thank you all your help.
PS:I don't use MFC,I just use CTreeViewCtrl in win32.
|
|
|
|
|
Why all that? You can take the '+' as a icon.
|
|
|
|
|
Hello Guys, I want make a some data via Windows Form using C++ Visual Studio 2010 when if I enter into textBox the string can convert tobe Txt file...
I have problem about it...
Please Help me 
|
|
|
|
|
Member 10415780 wrote: I have problem about it
What problem? Are you using pure Win32, MFC or WTL? Where do you want to save the text? Please give proper details of what you are doing and what does not work.
Veni, vidi, abiit domum
|
|
|
|
|
template<typename Container>
class Lock {
public:
Lock(const Container& container)
: c(container){
getMutexFor(c);
}
~Lock() {
releaseMutexFor(c);
}
private:
const Container& c;
};
How to realize the releaseMutexFor and getMutexFor?
|
|
|
|
|
Windows 7, visual studio 2008, C++
Reference: http://www.winsocketdotnetworkprogramming.com/[^]
I just discovered this site and now I think that a TPC/IP class can be created that does not use messages and needs no window. Async socket operation can generate events such as FD_SEND (it is okay to send now) and FD_READ (Windows has received some data for the application to capture.)
I can also declare and generate my own events. If I put the TCP/IP code in a class, make it a thread and crank it up, I can also pass it handles of events I have created along with the some other goodies in a single structure (such as the address of the buffer where the main app puts data to send out).
One of the key calls is WSAWaitForMultipleEvents() function where one of the arguments is an array of event handles. I did not recognize anything that places a limit on the type or category of events that it can received. (Is there any such thing as that? I know that Windows reserves event numbers below a certain value.)
Rather than a long post I will hope that the knowledgeable reader will recognize the intent and comment on the feasibility and/or loop holes and gotchas that await.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
|
OK, I am going that way, mostly, I think. After a bunch of searching I have found/concluded that the several version of WaitForMultiple[Event,Object] all wind up using this:
DWORD WINAPI WaitForMultipleObjects(
_In_ DWORD nCount,
_In_ const HANDLE *lpHandles,
_In_ BOOL bWaitAll,
_In_ DWORD dwMilliseconds )
from this page: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).aspx[^]
If the other versions, specifically the WSA versions are wrappers, and my primary goal is speed (i.e. minimum overhead), then it seems I should use the most fundamental call. This looks just about as simple as it could be. I am coding up a simple bare-bones thread to test it out. I think I have that ready will start of the main app that will create the events that the thread waits on.
Do you foresee any problems with this?
Edit: My searches have not produced a clear distinction between wait for EVENT and wait for OBJECT. They appear to be synonyms. Is that correct?
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
modified 25-Nov-13 22:28pm.
|
|
|
|
|
You'll need to implement a mechanism to shutdown and close the connected sockets if the client closes the connection (I used a WaitForSingleObject in the listening socket thread, with timeout 0 on each of the associated thread handles in turn, to see if it's still running, but it can be done in many other ways).
The WSA versions are wrappers around the WaitForSingleObject and WaitForMultipleObject, yes.
EVENT and OBJECT and HANDLE are effectively all the same thing - they are numerical identifiers that the system uses to look up internal things. In most cases . This means that you can wait on a thread handle (that identifier will be signaled when the thread terminates) for instance. There's a list of the things that can be waited on in the documentation.
Best of luck!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
