|
Just stick a post it note over the ones you dont want to see it in.
|
|
|
|
|
hi
I want to the file name I write in edit box is valid or not.
I check these characters \/:*?\"<>|
but there is some other chars like Unicode,\t prn,com1,com2 etc
is there any api to check file is valid or not.
thanks.
|
|
|
|
|
You can use CreateFile with the GENERIC_WRITE and CREATE_NEW flags and check if it fails.
|
|
|
|
|
Whether you can create a file on a disk driver at a specified location may depend on more factors than a list of allowed unicode characters burnt into windows. One such factor can be the filesystem of the drive you are writing to. For this reason I think the previously mentioned CreateFile() test is probably one of the best and most reliable solutions.
|
|
|
|
|
|
|
well I want to make career in programing and i am very good in c programming which i learn ownself, now i would learn next which programming language which have better career scope ! is it good to learn java ?
please anyone help me ?
|
|
|
|
|
|
Java and C# are pretty popular and I would say they are definitely safe choices even in long term. A better questions is: what kind of stuff do you like working on. If you are programming just for money then a rarely used "exotic" language (cobol, haskell, erlang, ...) at the right place and the right time can bring pretty good money.
|
|
|
|
|
pasztorpisti,
Very interesting observation... money value erodes where masses go....
|
|
|
|
|
This is the real world. You are trading one of your most valuable resources with your employer: time
|
|
|
|
|
You should learn English first.
|
|
|
|
|
Having been laid off way too many times, I've gotten a good take on demand. The hottest thing right now is WebServices using C#.NET. Java is up there too, especially Android, but falling fast in that category. Alas, my favorite, C/C++ is not.
|
|
|
|
|
I would suggest that you learn one language, which you already are, from what you write. Then, it becomes a simpler matter to translate that knowledge into another language. What is most important, in my opinion, is the ability to solve a real-world problem using a programming language; rather than mastering the nitty-gritties of a programming language itself.
|
|
|
|
|
Hi,
I am using the 2 step process CWinThread constructer and CreateThread to Create a UI thread
and I am getting a Access Violation somewhere in CWinThread::CreateThread
From the debugger I can already see that the thread has been created as the thread id from
DEBUG->threads matches m_nThreadID
The address where the access violation occurs matches the pointer to my derived CWinThread pointer
threadptr[I}
threadptr[i] = NULL;
threadptr[i] = new SockCLeintThread(start_port);
if (threadptr[i] == NULL)
m_pMainWnd->MessageBox((LPCTSTR)"SockClientThreadFail",NULL,MB_ICONERROR);
threadptr[i]->CreateThread(CREATE_SUSPENDED,0,NULL);
|
|
|
|
|
I have no idea whether this is connected but you should not be casting an ASCII string to a LPCTSTR ; the two may not be the same. Use the _T() macro to ensure your strings are generated to the correct mode for the project.
Use the best guess
|
|
|
|
|
fixed that up however that statement was never executed
I inserted this test
ASSERT(threadptr[i]->IsKindOf(RUNTIME_CLASS(SockCLeintThread));
|
|
|
|
|
Which means what?
Use the best guess
|
|
|
|
|
Richard
I don't know why I cleaned up my laptop and all of the sudden my code doesn't
work anyway a couple of points
After I create my CFramewnd and do a Showwindow it doesn't have a window handle its nulls
The Thread after creating the object
CWinThread->wm_pActiveWnd and CWinThread->m_pMainWnd are both NULL I populated via the debugger and CreateThread worked
|
|
|
|
|
Does your thread func start off by calling that AFX_MANAGE_STATE macro (or whatever it is called)? MFC threads need to do thkis else they screw up like this with all sorts of exceptions.
|
|
|
|
|
I populate both the
Main and active window of the thread
With my CFrameWnd * an that seemed to do the trick
Thanks
|
|
|
|
|
I believe AFX_MANAGE_STATE is only needed when exporting certain functions from a DLL which use MFC and load DLL resources.
|
|
|
|
|
I am sure I have had to use it in threads in MFC apps. Its been a while and of course it use could be required in many situations.
|
|
|
|
|
ForNow wrote: m_pMainWnd->MessageBox((LPCTSTR)"SockClientThreadFail",NULL,MB_ICONERROR);
Look at the underlined section. What are you hoping to achieve by the cast? If you're compiling for non-Unicode it does nothing and if it's a Unicode build it tells the compiler not to issue an error but to shut up and assume the ANSI string is a Unicode one, which it's clearly not. Best case scenario is a garbled string in the message box, worst case an access violation because of no double NULL terminator. This is the typical fate of the cast-happy: turning a compile-time error into a runtime one. Don't cast if you don't know what's going on or fumble around casting to suppress a compiler error.
You don't need any casts:
m_pMainWnd->MessageBox(_T("SockClientThreadFail"), NULL, MB_ICONERROR);
Steve
|
|
|
|
|
On which thread do you encounter the access violation? Can you post the piece of code that causes the crash? It would be nice to see the whole code of your worker thread and the codepieces from he main thread that are used in the communication with the worker (like thread creation, receiving messages from the worker).
As "UI thread" I usually name the thread that drives a gui framework, by default in MFC this is the main thread. In my opinion its better to use just one thread to handle the GUI (the main thread with MFC) because that is perfectly enough on every platform with any GUI framework despite the fact that on windows any threads are allowed to create their own set of windows but this is not a good practice. As I see your thread handles networking, how do you send/receive data? In case of multithreading a very nice strategy is minimizing the amount of shared data as much as possible usually by using message posting. Sometimes the amount of shared data can be reduced to zero along with the bugs. Post some code if possible and then we can give advices.
EDIT: Forgot to mention that in MFC there are two different kind of threads: UI threads that support message pumping for the UI and simple worker threads. There are two AfxBeginThread() functions and one of them creates a UI thread while the other creates a worker. You can simply go by creating a worker thread with a lightweight wrapper class around this worker AfxBeginThread() call. Deriving from CWinThread and using its CreateThread method is useful only if you want to reuse the same thread object to execute and exit many threads on it but reusing the same thread object twice is a bad design anyway because it introduces a lot of bugs. Its better to recreate thread objects. If you want to preserve state between thread executions then put the preservable state into a separate object and pass the same state object to every time you recreate the thread after the destruction of the previous thread. Often its better simply keep the thread running than terminating it and then starting another (but in my frameworks I always use pools and precreated threads, the frameworks hides the creation/destruction of threads and that is cool).
modified 17-Aug-13 11:06am.
|
|
|
|