|
|
I have an application and I am trying to generate an output file. type *.xls with c++ code.
how it is possible to create seprate sheet within the excel file and write to it.
|
|
|
|
|
maryami wrote:
how it is possible to create seprate sheet within the excel file and write to it.
It's very easy using Excel's COM interface (Automation). MSDN has several examples. This forum even has a few.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Hi!
I want to design a GUI in which I need to have bitmap containing buttons, something like actual phone, where buttons pressed simulate the actual pressing of buttons. What kind of architecture will be best to achive it. should i go for a Windows application or something like dialog boxes or Document/View Architecture. Any suggestions---------------
|
|
|
|
|
My suggestion here is to go for Windows application & MFC.
MFC provides you a possibility of customizing your window creation by deriving a class from CWnd. This allows you, when necessary, to do custom-painting routines for your window. I developed a skinned application a while back, and it's main design structure was as follows:
1. Created the actual bitmap of the UI, and the bitmaps of buttons
2. Created a 1-bit (two color) mask from the UI bitmap, and used a customized version of Jean-Edouard Lachand-Robert's BitmapToRegion function to get a valid Windows HRgn
3. Placed this HRgn as the window's clipping region by a call to CWnd::SelectClipRgn .
This results in a window with non-rectangular outline and a custom-painted UI. Of course, you can alternatively use drawing functions to draw the outline of the phone yourself, but this is very tedious work in Windows. However, it allows for a more realistic-looking UI than the bitmapping does. When using a bitmap, the creation of realistic-looking buttons is next to impossible, as you probably need to create skins for them as well.
The workload of creating a custom UI is huge, but doable, and if done right, you'll get very nifty results as well. But my suggestion is to go with MFC. Not only can you have access to the whole Win32 API if required, but you can also enjoy the benefits of a "true" OOP programming model.
If you feel like attempting this approach, here is a link to the aforementioned routine. The link resides on the CodeGuru website (BitmapToRegion routine.[^])
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
aroraavinash wrote:
should i go for a Windows application or something like dialog boxes or Document/View Architecture.
A Windows application is not mutually exclusive with dialog boxes or document/view architecture.
You can indeed place a bitmap (with the necessary "buttons" on it) on a dialog box, and when it is clicked, determine where in the bitmap the mouse was when the click occurred. That will tell you the "button" that was clicked. You could also place multiple button controls on the dialog. This is easier than the bitmap route but probably not as appealing to the eye.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Thanks for your suggestion. I was wondering how on a bitmap, can we detect, where the user has clicked and perform the necessary action. say i have a phone gui and button on it. how will i know that user pressed a particular button.
|
|
|
|
|
I've never done it before, but I believe PtInRegion() is used. Each of the "buttons" on the bitmap has a region. The point at which the mouse is clicked can be checked against each region.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I think this is the function I was looking for. I am new to MFC so don't have much idea about its various classes. Also is there a way by which we find the coordinates of various points in the bitmap? Because most of functions of CRgn Class wants the coordinates of point in the bitmap.
|
|
|
|
|
Hi David,
I will like to check one more thing from you that is using dialog based application still good, when my gui consist of a single(one piece skin)with nothing else. the buttons are part of skin itself. say for example if u take a picture of phone u will see buttons on it. i want to simulate pressing of those buttons. so will dialog based application helps in it.
Avi
|
|
|
|
|
aroraavinash wrote:
...is using dialog based application still good...so will dialog based application helps in it.
Yes, from what you've shown so far.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
hello,i have tried to write a filemanager in c++,im using the WIN32_FIND_DATA struct,to obtain file information,this seems to work okay apart from one thing,it list's all the files and directorys in my c:\ drive,but for some reason it dosent show "program files" as a directory,does anyboy have any idia what might be causing this?
thank you for your time.
chris
|
|
|
|
|
thes3cr3t1 wrote:
...but for some reason it dosent show "program files" as a directory...
What does it show it as?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
it dosent show it as anything,theese are the file artributes i got set: FILE_ATTRIBUTE_HIDDEN
FILE_ATTRIBUTE_COMPRESSED
FILE_ATTRIBUTE_SYSTEM
FILE_ATTRIBUTE_ENCRYPTED
do you know if i am missing anything there?
chris
|
|
|
|
|
thes3cr3t1 wrote:
do you know if i am missing anything there?
With the limited information you've provided, no.
I presume you have something akin to:
WIN32_FIND_DATA fd;
HANDLE hFind;
BOOL bContinue;
hFind = FindFirstFile(..., &fd);
if (INVALID_HANDLE_VALUE != hFind)
{
do
{
bContinue = FindNextFile(hFind, &fd);
} while (FALSE != bContinue);
FindClose(hFind);
}
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
yes very much like that here is what it looks like,
{
string filebuff;
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
hFind=FindFirstFile(Directory.c_str(), &FindFileData);
do{
if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_DIRECTORY )
filebuff += "dir";
if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_HIDDEN )
filebuff += "Hidden";
if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_COMPRESSED )
filebuff += "Compressed";
if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_SYSTEM )
filebuff += "System";
if( FindFileData.dwFileAttributes == FILE_ATTRIBUTE_ENCRYPTED )
filebuff += "Encrypted";
else
filebuff +=("%*s", 30, FindFileData.cFileName);
filebuff += "\n" ;
}while ( FindNextFile(hFind, &FindFileData) );
//do something//
return 0;
}
i hope this gives a better understanding of what i might be doing wrong here,
my only thought was that i was missing out a file artribute that i didnt know about,there is no reason why "Program Files" isnt shown as a directory after all it is a directory isnt it,even if program files was hidden,it should stil show up as a directory too shouldnt it?
this code is what i took from my source,as im a n00b if ya spot any mistakes please lemmi know,thanks again 4 ya time.
chris
|
|
|
|
|
Change your code to:
if ((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_HIDDEN) == FILE_ATTRIBUTE_HIDDEN)
filebuff += "";
if ((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_COMPRESSED) == FILE_ATTRIBUTE_COMPRESSED)
filebuff += "";
if ((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_SYSTEM) == FILE_ATTRIBUTE_SYSTEM)
filebuff += "";
if ((FindFileData.dwFileAttributes & FILE_ATTRIBUTE_ENCRYPTED) == FILE_ATTRIBUTE_ENCRYPTED )
filebuff += "";
else
filebuff +=("%*s", 30, FindFileData.cFileName);
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
wow thank you for such a speedy response,i tried what u said,but it didnt give the desired output,however with a little bit of tinkerin it seems to work nicly now,for some reson it now shows program files as a dir,i wold like to understand what was going wrong.this is the working code i now have
if( FindFileData.dwFileAttributes & FILE_ATTRIBUTE_HIDDEN)
filebuff += "<hidden>";
if( FindFileData.dwFileAttributes &FILE_ATTRIBUTE_COMPRESSED) filebuff += "<compressed>";
if( FindFileData.dwFileAttributes & FILE_ATTRIBUTE_SYSTEM) filebuff += "<system>";
if( FindFileData.dwFileAttributes & FILE_ATTRIBUTE_ENCRYPTED) filebuff += "<encrypted>";
it seemed to be the " == FILE_ATTRIBUTE_SYSTEM )" line that was making it go wrong,however if you hadnt of shown me the baove code i would have never noticed,now the next step for me is to learn from my mistake.
thanks again for such a fast response!;)
|
|
|
|
|
Hi all,
In my SDI applocation, I play the video file with the help DirectX.
Now I have to draw buttons over the running video image.
When trying for the same it's getting appear behind the video.
How to create buttons on the video
Thanks in Advance,
Chinna
|
|
|
|
|
Guys,
I am tring to dynamically move the positions of the child dialogs whenever the parent dialog is resized. But I started getting confused with the values passed to GetWindowPos for the dialogs.
Bsically, I have a parent dialog class, CMyDlg and the dialog contains a Group Box (IDC_SUBFRAME). the child dialog (CMainDlg) should fall into the centre of IDC_SUBFRAME. In CMyDlg::OnInitDialog(), I embedded the child dialog with following code:
CRect frameRect, childRect;
(GetDlgItem(IDC_SUBFRAME))->GetWindowRect(&frameRect);
pMainDlg = new CMainDlg();
pMainDlg->Create(IDD_MAIN_DIALOG, this);
pMainDlg->GetWindowRect(&childRect);
pMainDlg->SetWindowPos(this, frameRect.left + ((frameRect.Width() - childRect.Width())/2),
frameRect.top + ((frameRect.Height() - childRect.Width()) / 2),
childRect.Width(), childRect.Height(), SWP_NOZORDER);
pMainDlg->ShowWindow(SW_SHOW);
I found the child dialog was sitting in the Group Box frame, but not quite at the centre. Through the debug, I found the values of the CRects are quite strange:
frameRect {top=150 bottom=472 left=13 right=600}
childRect {top=30 bottom=132 left=4 right=517}
How come the frame's top and left are larger than the child dialog's, when the child dialog actually sits IN the frame when initialised. To better illustrate, the big box below is the frameRect and the small box within is the childRect.
---------------------
| |
| --------------- |
| | | |
| --------------- |
---------------------
From my understanding, GetWindowRect returns the coordinations in relation to the display (monitor). If so, wouldn't the frame's top and left values be smaller than the child dialog's?
Could anyone help me on this?
Thanks
|
|
|
|
|
I sympathize with you one this because I was doing the same thing last week only with more "layers" of windows and it got real confusing. Key points to remember:
1) Use GetClientRect to get the original size of the parent window
2) After you have resized with MoveWindow calculate the difference in width and height and store it somewhere for later use
3) Use GetWindowRect for the child window and MAKE SURE THE FIRST PARAMETER IS THE PARENT WINDOW...this is a common mistake that's easily overlooked.
4) Convert the rect.left and rect.top coordinates you just got with ScreenToClient to get client coordinates relative to the parent window
5) Final step, use SetWindowPos for the child windows with the difference in size (calculated earlier). eg.
// Apply the new height
lNewHeight = (rcTab.bottom - rcTab.top); // The original height calculate from GetWindowRect
lNewHeight += lDifference; // Add the difference calculated from the change in dimensions of the parent window. This will work regardless if the window became smaller or larger.
I hope I didn't confuse you more
|
|
|
|
|
georgiek50 wrote:
3) Use GetWindowRect for the child window and MAKE SURE THE FIRST PARAMETER IS THE PARENT WINDOW...this is a common mistake that's easily overlooked.
Thanks you for the reply georgiek50,
however, GetWindowRect for me does not taken two parameter, with the compiler error,
'CWnd::GetWindowRect' : function does not take 2 parameters
I found the variant of GetWindowRect in Platform SDK, but how do I use it. Also, from the descriptions, I cannot see how the additional parameter affects the coordinate values copied.
Thanks again
|
|
|
|
|
The "variant" I guess can only be used in Win32. If you mean the additional parameter being HWND it affects the values because it is getting the values relative to the values of of the window "below" it, just like GetWindowRect of the main dialog gets the values relative to the window (in this case the monitor/screen) "below" it. I'm sorry I can't explain this better than words, a drawing would be appropriate.
|
|
|
|
|
It's perfectly clear, thanks alot georgiek50
My development is under MFC, if considering my situation, GetWindowRect always get the values relative to the monitor/screen, correct? And as illustrated in my original post, how come the childRect left and top values are smaller than the frameRect's, when the display of the app actually has the child dialog sitting INSIDE the subframe. It does not seem to make sense.
|
|
|
|
|
It is smaller because: your main window rect.top = 150, correct, and your child is 30 correct? So relative to the top of your MONITOR, the main window is at 150 and the child is at 180 (150+30)...but relative to your main window it is only 30...do you see now? GetWindowRect apparently in MFC needs only one paramater because it uses the owner of the child window for reference/starting point coordinates.
|
|
|
|