|
You want to write data directly into your executable?! Really? Since MP3 files are data files, it's up to the program that uses them to define where the data goes. But I don't think you can guarantee you'll know where your compiler will put its binary data without delving into the details of the PE format.
I would suggest you create a binary resource in your executable that just contains the options you need. You can then load the values using the standard LoadResource calls.
When you need to update the resource, you can use the BeginUpdateResource, UpdateResource and EndUpdateResource functions to do so, without having to worry about copying and deleting your executable.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
I HAVE done this before, a long time ago and remember having no end of problems with it, although at this point I would have to dig out the program to say exactly what they were. At this point in time, I would say it's a probably a very bad idea, and almost certainly unnecessary. (When I did it I was writing for the DOS platform, and we didn't have binary resources.)
Quite frankly doing anything with a running executable anymore is just asking for trouble. I have yet to find a "nice" way to delete a running executable from within it, let along anything more complex (Yes, I've seen numerous solutions to this problem, but they all smack of "dirty hacks" to me."
Assuming you're programming for Windows, resources ARE probably your best bet.
As far as binary resources go, I use a CFile derived wrapper class which encapsulates the Win32 resource handling calls and makes the resource(s) look just like disk files. Mine came out of a commercial code library (Dundas Ultimate Toolbox) but Code Project or Code Guru might have something similar (it's worth a look).
Probably not much help, but there it is... 
Gamaliel Masters
"If I were to disprove 'I think, therefor I am', would I cease to exist?"
|
|
|
|
|
Hello,
Where can i find information in order to access data in an
*.mdb file using a console application under VC++6.0.
(I will need I/O access).
Thanks for help.
|
|
|
|
|
Try this:
http://msdn.microsoft.com/library/en-us/daosdk/html/dadidx01_3inr.asp?frame=true
or
http://msdn.microsoft.com/library/en-us/daosdk/html/davcsdk_5jcf.asp?frame=true
Martin
|
|
|
|
|
You have some options, that depends of wich technology you want to use.
For example you can use DAO, for that you have the CDAODatabase, CDAORecordset, etc, classes. You can use CDatabase Class usin ODBC, or you can use ADO, or OLE DB, for those you can find a lot of article in this site....
Good Luck!!!
Carlos Antollini.
|
|
|
|
|
hello !
when i try to debug my application, the following message appear to the
output window :
`First-chance exception in Democreator.exe (GDI32.DLL): 0xC0000005: Access Violation`
What does it mean ?
Thanks.
F.Julien
|
|
|
|
|
|
<br />
First and Second Chance Exception Handling <br />
<br />
Microsoft Win32 Application Programming Interface (API) included with: <br />
<br />
<br />
- Microsoft Windows NT versions 3.1, 3.5, and 3.51<br />
- Microsoft Windows 95 version 4.0<br />
<br />
<br />
Structured exception handling (SEH) takes a little getting used to, particularly when debugging. It is common practice to use SEH as a signaling mechanism. Some application programming interfaces (APIs) register an exception handler in anticipation of a failure condition that is expected to occur in a lower layer. When the exception occurs, the handler may correct or ignore the condition rather than allowing a failure to propagate up through intervening layers. This is very handy in complex environments such as networks where partial failures are expected and it is not desirable to fail an entire operation simply because one of several optional parts failed. In this case, the exception can be handled so that the application is not aware that an exception has occurred. <br />
<br />
However, if the application is being debugged, it is important to realize that the debugger will see all exceptions before the program does. This is the distinction between the first and second chance exception. The debugger gets the "first chance," hence the name. If the debugger continues the exception unhandled, the program will see the exception as usual. If the program does not handle the exception, the debugger will see it again (the "second chance"). In this latter case, the program normally would have crashed had the debugger not been present. <br />
<br />
If you do not want to see the first chance exception in the debugger, then disable the feature. Otherwise, during execution, when the debugger gets the first chance, continue the exception unhandled and allow the program to handle the exception as usual. Check the documentation for the debugger that you are using for descriptions of the commands to be used. <br />
Cheers!!!
Carlos Antollini.
|
|
|
|
|
Its a M$ known problem, It only Occurs in Win95 or Win98 - Best thing is to ignore it, as long as its not crashing your APP
|
|
|
|
|
Perhaps you should read the article above. It is not limited to Win9x.
Also, it is MS, or Microsoft not M$
|
|
|
|
|
I have a dialog which I have set as a tool window so it is always on top. Within this window I want to dynamically load buttons each with a different bitmap on. Someone has suggested that I use CreateWindow and pass a flag to say it will be of style BUTTON so I use the following code
CreateWindow("BUTTON",
"sample",
BS_BITMAP,
5,
5,
100,
100,
m_hWnd,
NULL,
NULL,
NULL);
I'm assuming that m_hWnd member variable should be a handle to the dialog box when it is shown, but when tested comes through as NULL and nothing is shown in the dialog box. What am I doing wrong?
Thanks for any help in advance
Nick
|
|
|
|
|
you must call ShowWindow() function after CreateWindow().
F.Julien
|
|
|
|
|
thanks, but do I put those in the constructor of the containing dialog because obviously the buttons will be part of this. When doing this I get an assertion error, I think its talking about a NULL handle to this dialog which I thought would be a problem.
Nick
|
|
|
|
|
Don't call CreateWindow on the buttons in the dialog's constructor - the dialog window won't be created yet so you can't use it as a parent window. Call CreateWindow in CYourDialog::OnCreate() (if you use MFC) or in response to the WM_CREATE msg (if non-MFC) instead. Since it's a dialog you can also put the calls in OnInitDialog/WM_INITDIALOG instead.
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
thanks a lot, that worked fine
Nick
|
|
|
|
|
You need to call to ShowWindow Function, but you are missing same values in the style parameter like WS_CHILD | WS_VISIBLE whit this last parameter don't you need to call to ShowWindow function.
Cheers
Carlos Antollini.
|
|
|
|
|
Button style should contain WS_CHILD and WS_VISIBLE:
CreateWindow("BUTTON",
"sample",
WS_CHILD | WS_VISIBLE | BS_BITMAP,
5,
5,
100,
100,
m_hWnd,
NULL,
NULL,
NULL);
You should also pass a child window id after m_hWnd.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
How do I get this child window ID?
So far I have the following code:
CreateWindow( "BUTTON",
"sample",
WS_CHILD | WS_VISIBLE | BS_BITMAP,
5,
5,
20,
20,
m_hWnd,
/*the child window ID will go here*/,
NULL,
NULL);
HBITMAP hBmp = (HBITMAP)::LoadImage(AfxGetInstanceHandle(), "c:\\1.bmp", IMAGE_BITMAP, 16, 16, LR_LOADFROMFILE);
::SendMessage((HWND)hButton, BM_SETIMAGE, (WPARAM)IMAGE_BITMAP, (LPARAM)hBmp);
Thanks for the help so far
Nick
|
|
|
|
|
How do I get this child window ID?
You don't get this ID, you have to come up with one yourself. This ID is passed back (as LOWORD(wParam) in WM_COMMAND) to the parent window when somebody clicks the button - you'll need to recognize which button was pressed, right?
You can use any scheme to create IDs to your buttons.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
So for example, I could set it as 966 by doing
int hButton = 966;
and including hButton under/after the m_hWnd parameter, because I already tried that. If that is correct, there is something else wrong, probably in the loading of the bitmap because when the program is run it show's no bitmap on the button.
Nick
|
|
|
|
|
hButton is a window handle, not a child ID. Store value returned from CreateWindow in hButton. Use some predefined constant and pass it as child ID to CreateWindow. Use the same constant when handling WM_COMMAND - you'll be able to respond differently to different buttons being pressed.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Sorted, thank you very much, much appreciated.
Nick
|
|
|
|
|
This is exactly what I'm doing, but in WM_COMMAND all WPARAM wp ever is is 0x0000FFFF
any ideas why?
I set it to
#define BTN_ONE 301
Thanks
|
|
|
|
|
I would like to create a function which could return 2 COleDateTime objects simultaneously, so i think that i could use a pointer of COleDateTime. But, as i'm a beginner in C++, i would like to know if someone could show me how we could do the allocation of this pointer, his deletion, and how i could return the dates, as i want the function return dates?
thanks in advance
gerald
|
|
|
|
|
You create the Objects dynamically
COleDateTime* pDate1 = new COleDateTime();
COleDateTime* pDate2 = new COleDateTime();
These objects are not gonna be destroyed if you leave the scope of this function !!
You can acess all the member - Fun´s and Var´s by using the -> operator:
pDate1->GetStatus();
You wanna get rid of them:
delete pDate1;
delete pDate2;
if this helps you... fine.. if not.. you can ask me..
Bernhard
- I heard if you play the Windows CD backwards, you get a satanic message.
- That's nothing, if you play it forward, it installs Windows!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
