|
1. Actually ask a question.
2. Use code tags when posting code.
< p r e> //without the spaces
your code
< / p r e> //without the spaces
|
|
|
|
|
I notice that you don't have any graphics code.
Is this a DirectX question ???
Show us your drawing code.
|
|
|
|
|
So what do you see when single-stepping through the code using the debugger? What is board being populated with? This is not to be confused with what you want it to be populated with. What are non_empty() and check() returning?
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
modified 13-Aug-13 10:46am.
|
|
|
|
|
The problem of your code (excluding minor fixes) is that the filling algorithm is probably wrong (it cannot complete the board). I suppose you should apply a backtracking algorithm.
Veni, vidi, vici.
|
|
|
|
|
Hello guys. I have this example which uses a design pattern. I don't know which design pattern is this.
I have this ClassMain, ClassParent, ClassChildOne and ClassChildTwo. ClassMain contains an array of type ClassParent, and stores the references of the two derived classes. Here is it how do I do it.
class CClassMain
{
#define MAX_COUNT 2
CClassParent arrParent[MAX_COUNT];
public void AddRef(CClassParent* ptr, int nIndex)
{
arrParent[nIndex] = ptr;
}
}
class CClassParent
{
static CClassMain* ptrMain;
public CClassParent() { ptrMain = new CClassMain;}
public void AddRef(int nIndex) {
ptrMain->AddRef(this, nIndex)
}
}
class CClassChildOne : CClassParent
{
public CClassChildOne
{
CClassParent::AddRef(1);
}
}
class CClassChildTwo : CClassParent
{
public CClassChildTwo()
{
CClassParent::AddRef(2);
}
}
The design pattern states that if I have to add new functionality (classes), it is really is easy now. I will simply increase the MAX_COUNT in CClassMain and derive the newly added class from CClassParent.
So what is the name of this design pattern and how do I study more about it specifically (and design patterns in general). Thanks for any info.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
|
I wouldn't say this to be the clean version of any of the popular patterns and without the context (sorrounding code) I would say this code isn't designed well and overcomplicated for no reason. This is typical among programmers who learn programming by reading pattern books. Many of the best programmers I know learnt programming without any patterns. By becoming a good programmer you instinctly find out and start using some patterns wihtout actually knowing the pattern and/or its name. I don't say its a bad thing to learn about patterns but trying to use them as golden hammers like many pattern-learners do is ridiculous. A programmer can be a very good programmer without knowledge of patterns and another one can be terribly bad coder with a lot of pattern knowledge. Knowing the patterns is good only when it comes to communication between programmers, its easier to say "visitor pattern" then describing how would you build up the classes and how would you call their methods... Don't overuse them, you become a better programmer if you try solving problems with simple methods and its OK to find it out later that your solution is very similar to one of the patterns. I've already worked on some codebases created by pattern magicians. This kind of terrible work can be one of the hardest to understand bloatcode on earth.
|
|
|
|
|
AmbiguousName wrote: it is really is easy now.
It isn't easy. It is fragile and hard to maintain. And I seriously doubt it will work in the vast majority of contexts. At best it seems to be a singleton registration service (which is pointless) and at worst it is simply broken.
AmbiguousName wrote: So what is the name of this design pattern
I doubt this code represents a generally accepted pattern.
|
|
|
|
|
I'm using opensource library (exprtk http://partow.net/programming/exprtk/[^]) on qt 5.1.0 64 bit with visual studio 2012. But I'm taking c1128 error. Full output of error: C1128: number of sections exceeded object file format limit : compile with /bigobj
|
|
|
|
|
|
The error message tells you exactly how to fix the problem...
Steve
|
|
|
|
|
how to get DeviceInstanceId using Scard*API?
|
|
|
|
|
Hi,
I want to use event object for synchronization between dialogs.
I am performing an operation to run a command from the command line. Now while the command is running I am displaying a dialog without Ok and Cancel buttons, to show the progress of the operation. Now I want to display a message to the user on completion of the operation. I want to use an event object for the same.
How to synchronize both operation. When operation is going on, user should be displayed with the dialog and when the operation completes, it should end the dialog and display a message to the user.
Can anybody help me with any sample code how to do the same.
Any help will be appreciated.
Regards,
Mbatra
|
|
|
|
|
One way of doing this is to have your command-line program send window messages to your dialog box to update the status and tell it when the command-line program is finished.
Look up the SendMessage API and use it to send a custom window message. Also look up the WM_USER constant and how it is used.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
There are several possible solutions to this problem on windows but maybe the simplest that came to my mind when I read your post is the following:
This task has nothing to do with command lines. Its an unimportant detail. You have your program running in its own process and you are launching another process with CreateProcess(). As a result you have a process handle to the other process. You can use this handle to wait for the termination of the other process for infinitely long time, for a specified amount of time (timeout), or you can poll this handle if the specified timeout value is zero using the WaitForSingleObject() or WaitForMultipleObjects() functions with the process handle. I would go by periodically (1-10 times per second) polling the handle from the gui thread, you can do that easily for example by setting up a WM_TIMER message for this purpose. Depending on your goals you can stop waiting for the running program anytime by stopping the WM_TIMER message and closing the handle and the dialog.
Since you have to be able to close the dialog yourself programmatically you can not use the MessageBox api that closes itself as a result of user input. You have to use your own modal or modeless dialog for this purpose. If you don't want the user to be able to interact with the other windows of your program while waiting then you need a modal dialog. If you don't want the user to be able to close your dialog by pressing X or by pressing alt+f4 then you have to handle the WM_CLOSE message by simply doing nothing (by not calling DestroyWindow(), EndDialog() or something similar).
So:
- launch the program with CreateProcess() and store the process handle for later use. Don't forget to close the handle with CloseHandle() when you no longer need it!
- At the same time you launch the process show your dialog and setup the WM_TIMER.
- In your the WM_TIMER message handler to you call WaitForSingleObject(process_handle, 0) and if the return value is WAIT_OBJECT_0 then the child process has finished so its okay to close the dialog.
At any time in your program you can stop waiting for example if you put some extra buttons to your dialog like "Stop waiting and let the child process run", or "Stop waiting and terminate child process"
Often there is no need for multithreading in case of multiprocessing. I think even the progress update is possible to solve from your WM_TIMER message handler, the question is the method we use to transfer this small piece of data (the progress) from the child process to the parent. The first two solutions that came to my mind:
- PostMessage / SendMessage mentioned by R. Andrew, I recommend PostMessage whenever possible to avoid unnecessary blocking of the child process. For larger messages use WM_COPYDATA.
You have to pass the HWND value to the child process in order to be able to do this for example on commandline or as an env var.
- dumbass solution: writing the progress into a specified file (either as text or binary integer) and from your wm_timer you always open the file, read out the stuff and show it.
- nonblocking pipe
- redirection of the output (stdout and/or stderr) of the child process, can be async or multithreaded
The correct implementation of communication between the two processes is probably the most complicated thing. Is the code of the child process yours, are you allowed to modify it or you have to parse the output of an existing prog to gather the progress?
|
|
|
|
|
Hi,
I have implemented using OnTimer function in which I will close the dialog after some specified time.
Now I have one issue.....I am displaying a message box that "operation completed.!" when the process completes.
I have CANCEL button on the dialog box.....
When user clicks the cancel button, I am closing and terminating the process. Now I don't want to display the message box when user has clicked the cancel button on the dialog.
I am doing like this.
CProgressDlg progDlg;
progDlg.SetPurpose(_T("Video, Please Wait........"));
if(progDlg.DoModal() == IDCANCEL)
{
WaitForSingleObject(pi.hProcess, 5000);
TerminateProcess( pi.hProcess, 0 );
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );
return FALSE;
}
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );
return TRUE;
This function is returning BOOL;
Now I want if user has clicked CANCEL button, then It should not display any message.
if I am checking against this function's return value....that if it returns false, simple return; otherwise if true, display a message to the user. Even on clicking the cancel button it displays the message;
Regards,
Mbatra
|
|
|
|
|
Both the WM_TIMER message and the "button pressed" event are handled on the same thread in some order so you don't have any multithreading issues/race conditions, these message handlers never get executed in parallel but you don't know which of these gets executed first and it can easily happen that both of them get executed at the wrong time. These message handlers of yours are called in the following way: the gui thread has a message queue. The operating system periodically puts a WM_TIMER message into it. When the user presses the cancel button the OS puts in a message that will call your "button pressed" handler. It can easily happen that there is a button pressed handler and a WM_TIMER message in the queue and when your Cancel button pressed handler executes its already later to turn of the WM_TIMER messages - you will still receive one WM_TIMER message because it is already in the queue. It can happen in reverse order too, if the WM_TIMER arrives first it can easily happen that you already have a button pressed event in the queue so you will receive it even if you disable the cancel button.
Because both handler are executed on the same thread you can create cooperation between the two handlers very easily. Use a global variable or preferrable a class member variable in your window class, you can safely use/modify the same variables from both handlers. I would use a bool variable that indicates whether the process is still "running" or not, whether it is still actual to execute a message handler. In the very beginning of both handlers you return if this variable is false. If any of the handlers is called when this variable is true you immediately set it to false and you execute the handler. This way only one of the handlers gets executed at most once regardless of the number of WM_TIMER and button pressed events accumulated in the message queue of the gui.
Cosmetics: When executing any of the handlers, disable the cancel button. Especially in the cancel handler because there you are waiting for up to 5 seconds.
BTW, with WM_TIMER you could implement a cancel that doesn't "freeze" the gui. Define an enum that indicates the process launch state:
enum EProcessLaunchState
{
EProcessLaunchState_NotRunning,
EProcessLaunchState_Running,
EProcessLaunchState_Cancelled,
};
Use this instead of the bool. From your cancel button handler just set this enum variable to EProcessLaunchState_Cancelled, then grey out the cancel button and return immediately. In your WM_TIMER message handler you act depending on the value of this enum. If its EProcessLaunchState_NotRunning you do nothing. If its EProcessLaunchState_Running then you just check whether it is still alive. If its EProcessLaunchState_Cancelled then you Still check whether the process is alive just like in case of EProcessLaunchState_Running but if alive you additionally perform the following: increase a wait_time variable and if the wait_time exceeds the timout then you call TerminateProcess. If you know that you set up a WM_TIMER with 1 second period then you know that 5 WM_TIMER calls is your timeout. This way your gui doesnt freeze. With your solution you couldnt even grey out the cancel button when it gets presssed because in worst case you don't return control to your main loop so the message queue processing of the gui thread is suspended for 5 seconds preventing your gui from receiving any events including the redraw of your cancel button as grey.
modified 12-Aug-13 11:50am.
|
|
|
|
|
Your answer is wrong, your supposition is wrong, and you post is too long.
He specificaly asked about events, why not give him the answer instead of bleating on about postmessage?
|
|
|
|
|
There isn't such thing that "too long post" on codeproject, there are only insulting post like your posts. If it is too long for you then don't read it.
|
|
|
|
|
|
So you have an event that is shared across your process. Your UI creates a thread that waits on the event (unless you dont mind the UI being blocked in which case the main thread can wait on the event.
Your processing thread then sets that even when it is done.
Your UI (main thread or wait thread) then gets its wait satisfied and goes on to notify the user.
|
|
|
|
|
Your solution is unreliable because in case of a child process crash you wait for the event forever. If you wait for the process handle on the thread then its an alternative for the WM_TIMER polling with multithreading.
|
|
|
|
|
Why do you assume he is using a child process and you can of course timeout on an event or trigger the event for all sorts of reasons.
Of course we dont knoq the design of his code, if he is creating a work thread to do the transfer, but he asked about events, not about spawning processes, so your answer to him and to me is still wrong.
|
|
|
|
|
I assume a child process because he has written about it in the body of the messasge: "running a commandline operation". What is this if not a child process or in some extreme circumstances a process launched somewhere else? But you know what, let OP to decide that: he never told that it isn't a child process.
What happens if you timeout the event? You start waiting for it again? Or you assume that the process has terminated when it is still running? And how do you signal to the gui thread when the event becomes signaled without bleating on SendMessage/PostMessage/PostThreadMessage? I think we can safely ignore "bleating on" this because OP probably knows this all...
OP tries to solve a problem and he isn't using the right tools, that's it. Maybe the title of the question was only about events but have you read the body of the message? I provided some alternative solutions because as many other problems this one can also be solved in many ways - all of them having its pros/cons. The solution involves waiting/polling the process handle either from a thread or from a periodic event from 1 thread.
My advice to OP was using the poll solution because beginner's multithreading solutions are buggy in 99% of the cases and polling is a perfect alternative in this case, wait cancellation is also easier to implement with polling.
My advice to you: Learn how to respect people and how to talk to them accordingly. Giving wrong answers and making mistakes is okay, submitting positive criticism is OK, submitting destructive criticism and destroying morale on the forums is not okay, treating yourself and your solutions perfect in contrast to others and others' solution is not okay. As I previously mentioned respect is mutual or nonexistent. The fact that my post is "too" long according to you is unimportant. Whether my solution is good or not? Let OP and others decide...
And you know what? Why don't you submit your solutions if you think you are that smart?
|
|
|
|
|
Hi pasztorpisti,
Thanx for the answers. I am not creating any child processes. I only have to notify the UI that operation is completed.
I have implemented the same by handling WM_TIMER messages.
Regards,
Mbatra
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
