|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
How are you inserting items in listbox. can you paste code which is causing problem
Regards
Abhishake Lahare
|
|
|
|
|
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..
|
|
|
|
|
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"
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
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?
|
|
|
|
|
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:
for (int cx = loc.x; cx < loc.x+loc.w; cx++)<br />
{<br />
for (int cy = loc.y; cy < loc.y+loc.h; cy++)<br />
{<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. 
|
|
|
|
|
What language? What toolkit? What object is this?
earl
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Hmm... I never thought of it that way... Thanks very much! 
Windows Calculator told me I will die at 28.
|
|
|
|
|
Hy. I'm trying to subclass the main winamp window in order to be able to get winamp internal information without using a timer(ie: current song artist, album, title, lenght, ..., volume, etc). I'm currently having trouble sbuclassing the winamp window (don't actualy know how to do it)
If some one could tell me what I did wrong, or what could be done better, I wold be realy grateful.
Here's the code:
========================================================================================
// gen_mymsc.cpp : Defines the initialization routines for the DLL.
//
#include "stdafx.h"
#include "gen_mymsc.h"
#include "gen.h"
#include "confDiag.h"
#include "wa_ipc.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
//
//TODO: If this DLL is dynamically linked against the MFC DLLs,
// any functions exported from this DLL which call into
// MFC must have the AFX_MANAGE_STATE macro added at the
// very beginning of the function.
//
// For example:
//
// extern "C" BOOL PASCAL EXPORT ExportedFunction()
// {
// AFX_MANAGE_STATE(AfxGetStaticModuleState());
// // normal function body here
// }
//
// It is very important that this macro appear in each
// function, prior to any calls into MFC. This means that
// it must appear as the first statement within the
// function, even before any object variable declarations
// as their constructors may generate calls into the MFC
// DLL.
//
// Please see MFC Technical Notes 33 and 58 for additional
// details.
//
// Cgen_mymscApp
BEGIN_MESSAGE_MAP(Cgen_mymscApp, CWinApp)
END_MESSAGE_MAP()
// Cgen_mymscApp construction
Cgen_mymscApp::Cgen_mymscApp()
{
// TODO: add construction code here,
// Place all significant initialization in InitInstance
}
int Cgen_mymscApp::winampInit()
{
AfxMessageBox(_T("Winamp has initiated the plugin."), MB_ICONASTERISK, 0);
return 0;
}
void Cgen_mymscApp::winampConfig()
{
CconfDiag *confDiag = new CconfDiag();
//INT_PTR
confDiag->DoModal();
}
void Cgen_mymscApp::winampQuit()
{
AfxMessageBox(_T("Winamp has destroyed the plugin!!!  "), MB_ICONASTERISK, 0);
}
int Cgen_mymscApp::winampSongChanged()
{
return 0;
}
// The one and only Cgen_mymscApp object
Cgen_mymscApp theApp;
// Cgen_mymscApp initialization
BOOL Cgen_mymscApp::InitInstance()
{
CWinApp::InitInstance();
hwndWinamp = FindWindowW(_T("Winamp 1.x"), NULL);
return TRUE;
}
/*********************************
* Winamp main functions *
*********************************/
WNDPROC lpWndProcOld = NULL;
LONG winampLong;
bool smth = false;
HWND winampHWND;
int init(){
AFX_MANAGE_STATE(AfxGetStaticModuleState());
winampHWND = FindWindow(L"Winamp v1.x", NULL);
winampLong = GetWindowLong(winampHWND, 0);
lpWndProcOld = (WNDPROC)SetWindowLong(winampHWND, GWL_WNDPROC, winampLong);
return theApp.winampInit();
}
void config(){
AFX_MANAGE_STATE(AfxGetStaticModuleState());
theApp.winampConfig();
}
void quit(){
AFX_MANAGE_STATE(AfxGetStaticModuleState());
theApp.winampQuit();
}
LRESULT CALLBACK MainWndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
AfxMessageBox(L"We has entered the the callback procedure");
if(message==WM_WA_IPC && lParam==IPC_ISPLAYING && smth==false)
{
AfxMessageBox(L"Winamp is playing");
smth = true;
return 0;
}
return CallWindowProc(lpWndProcOld,hwnd,message,wParam,lParam);
}
winampGeneralPurposePlugin plugin =
{
GPPHDR_VER,
"Multi - Yahoo! Messenger Status Changer (gen_mymsc.dll)",
init,
config,
quit,
};
extern "C" {
__declspec(dllexport) winampGeneralPurposePlugin *winampGetGeneralPurposePlugin(void)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
return &plugin;
}
}
===============================================================================================
http://rafb.net/paste/results/6vBdVY85.nln.html <-the same code with sintaxHighlight
|
|
|
|
|
u0m3 wrote: winampLong = GetWindowLong(winampHWND, 0);
Did you just make this up? 0 is DWL_MSGRESULT.
u0m3 wrote: lpWndProcOld = (WNDPROC)SetWindowLong(winampHWND, GWL_WNDPROC, winampLong);
lpWndProcOld = (WNDPROC)SetWindowLong(winampHWND, GWL_WNDPROC, (LONG) &MainWndProc);
|
|
|
|
|
I started using this code for subclassing the main window: http://forums.winamp.com/showthread.php?s=&threadid=227006
Here's the relevant part:
int init()<br />
{<br />
lpWndProcOld = (WNDPROC)SetWindowLong(plugin.hwndWinampParent,GWL_WNDPROC,(LONG)WndProc);<br />
<br />
HWND pe = (HWND)SendMessage(plugin.hwndWinampParent,WM_WA_IPC,IPC_GETWND_PE,IPC_GETWND);<br />
lpPEProcOld = (WNDPROC)SetWindowLong(pe, GWL_WNDPROC, (LONG)PlaylistEditorProc);<br />
<br />
return 0;<br />
}
I used only the first part...
lpWndProcOld = (WNDPROC)SetWindowLong(plugin.hwndWinampParent,GWL_WNDPROC,(LONG)WndProc);
I got errors for plugin and (LONG)WndProc -> don't know how to get them... sorry... I'm a n00b.
|
|
|
|
|
hfry wrote: lpWndProcOld = (WNDPROC)SetWindowLong(winampHWND, GWL_WNDPROC, (LONG) &MainWndProc);
What is MainWndProc? Or more importantly, how do I get it?
|
|
|
|
|
It's your window procedure...
LRESULT CALLBACK MainWndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
|
|
|
|
|
I have a fairly large application (MFC App) developed in Visual C++ 6.0.
As it's growing constantly, it's getting bigger and bigger and I've started to modularize it by adding DLLs with Visual Studio 2003 and now Visual Studio 2005.
Is there a better method nowadays that I can use to add new modules to the app or is DLL still the classic method used ?
Thanks.
|
|
|
|
|
vcpp_cgr wrote: is DLL still the classic method used
Pretty much the same, except that it's called assembly in the context of .NET Framework.
Best,
Jun
|
|
|
|
|
How can I recieve HBITMAP from clipboard? In both cases I;m getting empty bitmap:
1. HGLOBAL hMem = GetClipboardData( CF_BITMAP );
HBITMAP hBitmap = (HBITMAP) GlobalLock( hMem );
2. HBITMAP hBitmap = (HBITMAP) GetClipboardData( CF_BITMAP );
And second question:
how can I then create CBitmap object from HBITMAP?
Thanks for any help 
~~~~
|
|
|
|
|
HBITMAP handle = (HBITMAP)GetClipboardData(CF_BITMAP);
CBitmap * bm = CBitmap::FromHandle(handle);
Do the chickens have large talons?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
