C / C++ / MFC

can tab control join project togehter?

13-Jul-06 18:34

Firstly if nchar is what you're using to determine how many spaces you need to add, you need to reverse your logic there, it should be:

nchar = 20 - sBuf.GetLength();

Rather than the other way around.

Now if you're thinking of the Space method from Visual Basic, C++ doesn't have that same method. You could however quickly write something up yourself using Insert as another poster mentioned. For instance:

int i = 0, len = sBuf.GetLength();
while (i < nchar)
{
sBuf.Insert(len + i, ' ');
i++;
}

Kelly Ryan

mimimimilaw13-Jul-06 17:21

mimimimilaw

13-Jul-06 17:21

I am a beginner in MFC. I want to ask if tab control can join two project together? and how can i do it?
thx a lot. Smile | :)

Re: can tab control join project togehter?

see me13-Jul-06 17:44

see me

13-Jul-06 17:44

Can you tell some thing about ur requirement..

Dream bigger... Do bigger...Expect smaller
aji

Re: can tab control join project togehter?

mimimimilaw13-Jul-06 17:47

mimimimilaw

13-Jul-06 17:47

I only want to join two project together but use the same dlg.

Re: can tab control join project togehter?

Abhi Lahare13-Jul-06 18:02

Abhi Lahare

13-Jul-06 18:02

which projects? and in which dlg?

Regards
Abhishake Lahare

Limiting # of columns in multi-column listbox

KellyR13-Jul-06 17:15

Re: Limiting # of columns in multi-column listbox [modified]

13-Jul-06 17:15

Hihi, just one quick question:

I have a multi-column listbox that I insert bitmaps into. I want it to have a max of 8 columns, and have an essentially unlimited number of rows. Right now it seems to limit number of rows by the listbox height (i.e. my vertical scrollbar never shows up because it refuses to insert items below the bottom of the listbox), and have an unlimited number of columns. How can I fix this so that the columns are limited and the rows are not?

Thanks!

Kelly Ryan

Abhi Lahare13-Jul-06 17:36

Abhi Lahare

13-Jul-06 17:36

The Items might get inserted in row, but you may not able to scroll the list,
check if you have LBS_DISABLENOSCROLL style that may be causing problem.

Regards
Abhishake Lahare

-- modified at 23:36 Thursday 13th July, 2006

KellyR13-Jul-06 17:44

13-Jul-06 17:44

LBS_DISABLENOSCROLL is not set, the items are all inserted but only into the rows that 'fit' into the height of the listbox, all the other items are inserted in the columns. I just need a way to limit the number of columns somehow or force it to insert in rows after it has X number of columns.

Kelly Ryan

Re: Limiting # of columns in multi-column listbox [modified]

Abhi Lahare13-Jul-06 18:01

Abhi Lahare

13-Jul-06 18:01

How are you inserting items in listbox. can you paste code which is causing problem

Regards
Abhishake Lahare

KellyR13-Jul-06 18:10

13-Jul-06 18:10

I'm just using LB_INSERTSTRING, like so:

HBITMAP hbmp;
hbmp = <whatever bitmap="" i'm="" inserting="" here="">
SendMessage(window, LB_INSERTSTRING, (WPARAM)item_index, (LPARAM)hbmp);

I don't know that it's a problem so much as just a default behavior, but I can't figure out how to change it and I need vertical scrolling on this list rather than horizontal, but I need multiple columns. I don't want to have to go and write a custom class to do this, there should be a simple way to just limit the # of columns, I hope..

Here's a diagram of the problem:

Assuming the listbox height is '3 items' this is what it currently does, even when the listbox width is only '5 items':

A A A A A A A A A A A A
A A A A A A A A A A A A
A A A A A A A A A A

What I WANT it to do is this:

A A A A A
A A A A A
A A A A A
A A A A A
A A A A A
A A A A A
A A A A

Where it shows the top 3 rows and the user has to scroll down to see the rest.

If there was some sort of windows message to set # of columns, or something? I've been looking but I can't seem to find one..

Ryan Binns13-Jul-06 18:34

Ryan Binns

13-Jul-06 18:34

KellyR wrote:
How can I fix this so that the columns are limited and the rows are not?

Unfortunately, you can't with a list box. All you can do is set the column width, which is not what you want.

KellyR wrote:
I have a multi-column listbox that I insert bitmaps into. I want it to have a max of 8 columns, and have an essentially unlimited number of rows.

So your list-box items are bitmaps? You could try using a grid control, or a list-view control with the LVS_ICON view style - just set the icon size and spacing such that you have the correct number of columns in each row.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

KellyR13-Jul-06 18:36

anti-debug product for MFC?

13-Jul-06 18:36

I was thinking about using LVS_ICON when I made the thing but I was hoping it wouldn't matter.. darn it. I'll give that a shot, thanks for help!

Kelly Ryan

WM_TIMER

thathvamsi13-Jul-06 16:48

thathvamsi

13-Jul-06 16:48

Hey all,
Finally, I managed to come up with a code snippet for WM_TIMER.
I have to send a packet from PC to the serial device(RABIT3000) at regular intervals 'x'seconds.

heres the code

On_begin()
{
Sendpacket();
SetTimer(m_nTimerID,x,NULL);
}

OnTimer(UINT nIDEvent)
{
// do the needful
Sendpacket();
CWnd::OnTimer(nIDEvent);
}

On_Stop()
{
KillTimer(m_nTimerID);
}

IS this correct? What more do I need to do? Where do I declare like "afx_msg void OnTimer(...)?

Thanks in advance.

Re: WM_TIMER

see me13-Jul-06 17:33

see me

13-Jul-06 17:33

You need to call ON_WM_TIMER() message in BEGIN_MESSAGE_MAP

and also declare
afx_msg void OnTimer(UINT nIDEvent);

in header of class

Dream bigger... Do bigger...Expect smaller
aji

darbien siamak13-Jul-06 16:16

darbien siamak

13-Jul-06 16:16

I'm looking for a solution that will prevent debuggers like soft-ice being used on the MFC application. Is there any good recommandations for products outthere that I can purchase? I cam across a product called EXECRYPTOR but not sure if it is worth the money.

Also with my limited knowledge on software cracking, the way MFC works is that it calls a lot of other DLL's (MSVCRT*.DLL, MFC*.DLL). Is this potentially dangerous for other people to reverse-engineer? Is there a good way to prevent this?

thanks for any advice!

Re: anti-debug product for MFC?

Phil.Benson13-Jul-06 21:28

Phil.Benson

13-Jul-06 21:28

To be honest, do you really need to protect your application to that extent? Regardless of how much time and money you put into protecting your application, it can and will be cracked (if the incentive is there), regradless how you protect it. Even the anti-ice products are "crackable". I suppose it all winds down to the application audiance, i.e. the user base. If it is mainstream, then perhaps protection of sorts is required, if not, then I suggest leaving anti-ice products alone, and use support/maintenance as an incentive to use the product "legally".
Just my tuppence

Phil

Who the f*** is General Failure, and why is he reading my harddisk?

Filling a square?

Lord Kixdemp13-Jul-06 12:49

Lord Kixdemp

13-Jul-06 12:49

Hello everyone!
OK, suppose I have a square of pixels... I want to fill the squares with cyan color. How would I do that? I tried this:

// width<br />
for (int cx = loc.x; cx < loc.x+loc.w; cx++)<br />
    {<br />
// height<br />
        for (int cy = loc.y; cy < loc.y+loc.h; cy++)<br />
        {<br />
// fill<br />
            this->screen[cy*loc.w+cx].Attributes = color;<br />
        }<br />
    }

Something tells me the cy*loc.w+cx formula is wrong... Can anyone help me? Thanks!

Windows Calculator told me I will die at 28. Frown | :(

earl13-Jul-06 13:22

earl

13-Jul-06 13:22

What language? What toolkit? What object is this?

earl

Lord Kixdemp13-Jul-06 16:10

Lord Kixdemp

13-Jul-06 16:10

Language: C++
Toolkit: Windows Console API

I just wanted the basic formula to fill a square... Thanks!

Windows Calculator told me I will die at 28. Frown | :(

Rilhas17-Jul-06 12:47

Rilhas

17-Jul-06 12:47

I assume the representation of the image in memory is sequential X and stepped Y. This would mean that pixel X=0/Y=0 is followed in memory by pixel X=1/Y=0, then X=2/Y=0, etc.

With this memory representation of the image your formula would be correct. If your image is 100 pixels wide then the pixel X=17/Y=35 would be located in memory array cell 35*100+17.

However, you should note that your code could have several optimizations, applicable in any language. The most important of them is that all modern processors use cache machanisms, which are exploited to their best if memory accesses are sequential.

This means that your outter loop should be the Y loop, and the inner loop should be the X loop. Something like this:

for (int cy = loc.y; cy < loc.y+loc.h; cy++) {
for (int cx = loc.x; cx < loc.x+loc.w; cx++) {
this->screen[cy*loc.w+cx].Attributes = color;
} // next x
} // next y

The loop order is simply reversed. With this arrangement the access the processor needs to the main memory is optimized, because the X loop accesses the memory sequentially (the pixels are arranged so that pixel X+1 follows pixel X, and the cache can take advantage of this). This can lead to typical improvements of 10x or more (of course, depending on the overall performance of the language). If the Y loop is the inner loop, then no memory access is sequential, since (from the cache point of view) the memory will be accessed in (potentially) large leaps and never sequentially. However, with large caches and small images, the cache could hold all the image square and still behave optimally (the cache would be helping the performance of your code, and your code would not be helping the cache at all).

Another simple optimization would be something like:

int y0=loc.y;
int y1=loc.y+loc.h;
int x0=loc.x;
int x1=loc.x+loc.w;
int pixel_index;
for (int cy = y0; cy < y1; cy++) {
pixel_index=cy*loc.w+cx;
for (int cx = x0; cx < x1; cx++) {
this->screen[pixel_index].Attributes = color;
pixel_index=pixel_index+1;
} // next x
} // next y

The advantages of the previous code are several:

1) Avoid an addition with each iteration of the outter y loop (y1 is precomputted).

2) Avoid an addition with each iteration of the inner x loop (x1 is precomputted).

3) Avoid one multiplication for each pixel. Since the pixel_index is computed at the start of each loop, we take advantage from the fact that adjacent X pixels correspond to adjacent addresses in memory. So, we just increment pixel_index, avoiding the multiplication for each X loop. This could be further inproved if we precomputed how much pixel_index would have to be incremented at the end of each X loop to end up in the first X of the next line, but this typically doesn't improve performace much.

The optimizations 1) and 2) above increase the clarity of the code, but are typically not very significant. Optimization 3) may be much more significant, but it reduces clarity. In any case, these optimizations are noticeable more and more as images become larger and larger.

I hope that you find these very easy to implement hints helpful.

Rilhas