|
Vaclav_Sal wrote:
Display = new int *[10];
// display rows
for (int i = 0; i < 20; i++)
I question this. Shouldn't the for() loop only run 10 times instead of 20?
"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
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
You have two main problems.
Firstly you create 10 rows and then try to initialise 20 of them each with 10 columns, try:
int **Display = new int *[10]; for (i = 0; i < 10; i++) Display[i] = new int[20];
When adding your counter values into the array you increment your Display pointer (which indexes the rows only), which means that after 10 iterations it is pointing to an invalid address. Try using the offset values for row and column instead, as it will also make your code clearer, thus:
for ( i = 0; i < iRow; i++)
{
for (j = 0; j < iCol; j++)
{
Display[i][j] = iCount;
++iCount;
}
}
|
|
|
|
|
Thanks, I was pretty sure I was doing it wrong using pointers while assigning the values.
I also had the pointers array redefined in constructor.
Sure would be easier with real debugger, oh well.
Now it plays nicely.
Thanks
Cheers Vaclav
|
|
|
|
|
Happy to help.
Vaclav_Sal wrote: I was pretty sure I was doing it wrong using pointers
I had to think for quite a while about that before I realised why it was not working.
|
|
|
|
|
how to do image operations using mfc
|
|
|
|
|
|
|
MFC has almost nothing in terms of image processing functionality. if you want to do anything more than simply displaying a BMP, you will need to use a dedicated image processing library. there are many of those around.
|
|
|
|
|
Hello everyone,
as an academic exercise and because, apparently, I'm founding myself with some free time to spend, I'm trying to create a set of C++ classes to abstract away the Win32 APIs related to user interface creation (I'm talking about CreateWindowEx, Translate/DispatchMessage, and so on). Yes I know I'm reinventing the wheel, and no, I don't want to use Qt nor wxWidgets; as I said, this is an academic exercise.
So, I have created a window class, which basically wraps many HWND-related functions, and adds support for children containment (as in Windows Forms Form.Controls) and event handling (using boost::signals2). I also have created derived classes (i.e. button, textbox, etc.) which I have subclassed from existing WNDCLASSes ("BUTTON", "EDIT", etc.) and have their window procedure redirected to each derived class internal methods, thus I'm able to catch any WM_ message and launch the corresponding boost::signal2 signal.
Now, in order to achieve this, I had to keep, at the very least, a HWND as a private member of my window class. What I would like to do is to abstract away this HWND, because if it appears in the header then the consumers will have windows.h #included and I'm trying to avoid this. So I turned to the pimpl idiom and did something like the following:
class window : public container
{
public:
...
private:
struct windata;
std::unique_ptr<windata> _data;
};
struct window::winadata
{
HWND me;
};
window::window()
{
...
_data->me = CreateWindowEx(...);
}
So this worked for window class, but then, for the derived classes, I need access to windata structure (for there is the needed HWND). Having struct windata declared as protected won't work, because in button.cpp windata is an incomplete type, and thus it won't compile.
So I'm looking for alternatives here, and wanted to ask CPians opinions on how to best achieve this abstraction. By digging on wxWidgets and other's source code, I have come up with a few alternatives:
* Have struct windata defined in its own header file and have it included in the cpps as needed.
* Create a window_base class and then have a window_win32 class inheriting window_base, and put all the Win32 specific code in the derived class (this is what wxWidgets do, I think).
* Follow the abstract factory pattern instead, which (I think) is what John Torjo does with his Win32GUI library.
* Some other options involving global variables and template voodoo.
What are your thoughts / recommendations? Thanks in advance!
modified 9-Nov-14 23:37pm.
|
|
|
|
|
I would recommend your first alternative:
Have struct windata defined in its own header file and have it included in the cpps as needed.
There is a simpler solution, which is practical but not academically pleasing. WinDefs.h has:
typedef HANDLE HWND;
WinNT.h has:
typedef void *PVOID;
typedef PVOID HANDLE;
So you could define a protected typedef in your base class:
typedef void* WindowHandle;
And use that throughout. In a sense, this is cheating, because it depends on looking behind the facade, and it could, at some point stop being valid, since Microsoft could, in theory, change the definitions in a later version of Windows. If you use their definitions, you'd be safe. However, given how much code would break, it's exceedingly unlikely they'll ever change the definitions of those types.
|
|
|
|
|
Thank you Orjan,
yeh I was lurking the windef file and actually got this working:
struct opaque
{
int* data;
};
typedef opaque* opaque_ptr;
And then this works:
HWND wnd = GetSomeWindowHandle();
opaque_ptr h = reinterpret_cast<opaque_ptr>(wnd);
wnd = reinterpret_cast<HWND>(h);
But as you said, it feels like cheating. I'll give it further thought, and if I can't find anything else, I think I'll be using this approach.
Thanks again for the help! Best regards.
modified 10-Nov-14 13:14pm.
|
|
|
|
|
If you use a typedef of void* you will not need any reinterpret_cast calls, as it's all the same type. The problem of using a pointer to a struct like this is that someone looking at the code would be curious about what's in
h->data so it is misleading to have it if it's never used.
|
|
|
|
|
I've used a couple of way of getting around this:
- use the void pointer hack
- wrap every WIN32 operation in another class called window_handle then implement window classes as needed using that. I also replaced the concrete base class with an interface class as virtually all the code that would have been saved by implementation inheritance ended up in the window_handle. This is similar to your shared PIMPL but the PIMPL is actually a full blown object in its own right and does all the WIN32 stuff and doesn't just hide an HWND.
Another way I want to experiment with further decouples the windows guff from the logic of what the window actually does. The idea is to have a window class that has a message handler interface pointer but I haven't tried that yet. You'll be getting a similar effect using boost::signal2 to route messages.
|
|
|
|
|
Thank you Aescleal, I think I'll use the void pointer.
Aescleal wrote: The idea is to have a window class that has a message handler interface pointer but I haven't tried that yet.
I'm trying that just yet, and I have already subclassed some existing common controls to get their WndProc and route the messages accordingly through boost::singal2, but on my own terms. I think this is what Windows.Forms do.
Thanks for the help!
|
|
|
|
|
I have an SDI app (test app), where I spread an CGridCtrl ... I wonder how to catch CMyView::OnMouseMove, because I saw that this handler is never fired ... can you help me, please ?
|
|
|
|
|
I try that:
void CGridViewDemoView::OnMouseMove(UINT nFlags, CPoint point)
{
TRACE("aaaaaaaaaaaaaaaaaaaaaaaaaa\n");
CView::OnMouseMove(nFlags, point);
}
Taked from here.
|
|
|
|
|
You probably forgot to add the corresponding entry to your message map:
BEGIN_MESSAGE_MAP(CGridViewDemoView, CView)
ON_WM_MOUSEMOVE()
END_MESSAGE_MAP()
|
|
|
|
|
I did that:
BEGIN_MESSAGE_MAP(CGridViewDemoView, CView)
ON_WM_SIZE()
ON_COMMAND(ID_TOGGLE_READONLY, OnToggleReadonly)
ON_WM_ERASEBKGND()
ON_WM_MOUSEMOVE()
ON_COMMAND(ID_FILE_PRINT, CView::OnFilePrint)
ON_COMMAND(ID_FILE_PRINT_DIRECT, CView::OnFilePrint)
ON_COMMAND(ID_FILE_PRINT_PREVIEW, CView::OnFilePrintPreview)
END_MESSAGE_MAP()
|
|
|
|
|
Then there are two other possible sources:
- The message is handled by a window that is over your view (e.g. the grid control).
- The mouse is captured by another window (using CWnd::SetCapture).
For the first case you should not add the handler to the view but to the grid control (which requires modifying the sources of the grid control or deriving a new class).
|
|
|
|
|
Was the first situation, and I extended CGridCtrl in order to not mess up CGridCtrl ... Thank you.
|
|
|
|
|
Does anybody know of any third party libraries that I can use to get the prices of call options on stocks? I would like quotes on put prices also?
Bob
|
|
|
|
|
Google is probably a better place to check.
Also, unless you are writing code in C/C++ to call the libraries then this forum wouldn't be the right place anyway.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Thanks for the response. I am writing C++ code and I am looking for a C++ callable library. Preferable an open source library. Also, before posting my question here, I did several searches using Google. However, they failed to turn up what I am looking for.
Bob
|
|
|
|
|
|
BobInNJ wrote: Does anybody know of any third party libraries that I can use to get the prices of call options on stocks?
Just to be clear whatever this is wrapped in, it still, of course, requires a service.
And the service, not the library, is going to be what the significant part of the cost is. And that will be a recurring cost. Not to mention of course that there will probably be other functionality associated with the service which is probably a significant consideration - for example how exactly they manage the money that must exist.
Since it is a service then it is probably best to look for the service or services that best meet the business needs and then look for libraries specific to those after that. If there is no C/C++ interface then write one.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
