|
Member 11227854 wrote: ...i am building a application that contains a compiler and i want to know how to add it. I am still a newbie...
Those two things typically do not go together well, at least not without a lot of prior knowledge. How about a less ambitious project (or two) to get you acquainted with C/C++/MFC development?
"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
|
|
|
|
|
<pre lang="text">
I am trying to build a two dimmensional array - accessing LCD of 10 rows and 20 columns and be able to pass the pointer(s) to a function.
The function / method is declared in class and so is the pointer:
boolean DisplayImage(int **Display);
int **Display;
</pre>
And the function:
<pre lang="c++">
boolean CImage::DisplayImage(int **Display)
{
#ifdef DEBUG
TRACE("CImage::DisplayImage ** ", 1);
#endif
int i, j, iRow, iCol;
iRow = 10;
iCol = 20;
int iCount = 0;
for ( i = 0; i < iRow; i++) {
for (j = 0; j < iCol; j++) {
lcd_i2c.clear();
lcd_i2c.print("location ");
lcd_i2c.setCursor(0, 1);
lcd_i2c.print("row i ");
lcd_i2c.print(i );
lcd_i2c.print(" col j ");
lcd_i2c.print(j );
lcd_i2c.setCursor(0, 2);
lcd_i2c.print("Display ");
**Display = iCount++; // set test value - works
lcd_i2c.print(**Display); // display is OK
// lcd_i2c.setCursor(0, 3);
// lcd_i2c.print("mask center ");
// lcd_i2c.print(**image );
**Display++;
delay(500);
}
}
return true;
}
</pre>
Here is how I initialize the array
<pre lang="c++">
CImage::CImage (void)
{
// initialize array using pointers
// int **Display;
Display = new int *[10]; // display rows
for (int i = 0; i < 20; i++)
Display[i] = new int[10]; // display columns
}
</pre>
Here are my questions:
1. I need some explanation about this syntax "Display = new int *[10]" - is the "Display " the variable name ?
2. I may have the rows / columns reversed because<b> I really do not understand how is the array initialized</b>.( <b><b></b>That is my main question</b> - I can take it from there ).
3. Unfortunatelly the example I got this from had 10 by 10 array so I am lost as far as what are the columns and what are the rows.
4. I use rows and columns because that is the underlying hardware and I understand it is irrelevant as far as multidimmensioal array goes.
5. Under present initialization I cannot get the LCD print pass first "row". The processor just stops ( Arduino Due). I would expect it to keep printing even if I runs out of valid pointer, but that is not the case. I sure would like to know why. ( It "runs" GCC compiler).
Thank you for your time and help. Appreciate it.
Cheers Vaclav
PS I do not have a real debugger and using the LCD as "trace / debug "
|
|
|
|
|
Vaclav_Sal wrote: 1. I need some explanation about this syntax "Display = new int *[10]" - is the "Display " the variable name ?
Yes
Vaclav_Sal wrote: 2. I may have the rows / columns reversed because<b> I really do not understand how is the array initialized</b>.( <b><b></b>That is my main question</b> - I can take it from there ).
This is actually a matter of how the array is used (i.e. however you define it, or if you're using someone else's code, how they define it) since it's not really a matrix.
Vaclav_Sal wrote: 3. Unfortunatelly the example I got this from had 10 by 10 array so I am lost as far as what are the columns and what are the rows.
Without looking at the code, your guess is as good as mine... 
Vaclav_Sal wrote: 5. Under present initialization I cannot get the LCD print pass first "row". The processor just stops ( Arduino Due). I would expect it to keep printing even if I runs out of valid pointer, but that is not the case. I sure would like to know why. ( It "runs" GCC compiler).
Does it say anything when it stops? ...is it crashing?
|
|
|
|
|
It basically stops here
lcd_i2c.print(**Display); // display is OK
So it may be the LCD problem.
If it crashed it should restart, but there is something different is Due (SAM) code from AVR code on start up, so it my be just stuck.
I think I am assigning the values to the wrong pointer after the first array is done.
I actually should use plain array and not pointers since I need to do convolution with 3x3 matrix to detect edge.
I am not sure this is correct - the function gets a double pointer and than I assign to double pointer. But if I assign Display = iCount the compiler does not like it and I am still learning how to "translate" compiler / Arduino error messages.
<pre lang="c++">
lcd_i2c.setCursor(0, 2);
lcd_i2c.print("Display ");
**Display = iCount++; // set test value - works
lcd_i2c.print(**Display); // display is OK
// lcd_i2c.setCursor(0, 3);
// lcd_i2c.print("mask center ");
// lcd_i2c.print(**image );
**Display++;
delay(500);
</pre>
|
|
|
|
|
|
You responded to me, not OP.
|
|
|
|
|
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).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
