|
Generally you cannot save out pointers unless you were to create your own heap manager, and that is a task unto itself.
What I would suggest to get the same effect that you are shooting for, is create a serializing function to store your objects to disk. All of the objects and strings that are shared through pointers should be stored in a table with an index or a handle ID. Then when you want to associate a the original pointer to the parent object, store the ID or index in the file instead.
Then when you reload the file, you will have recreate the objects in the tables, but you can store the IDs or indices in the tables. And when you recreate the objects that use the pointers, you look up the pointers in the tables that you created.
Good Luck
Build a man a fire, and he will be warm for a day Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
The pointers really point to some house made objects which are generated from a serial flow of data and then "consumed" by the app.
The problem is that this app might be receiving data for a long time without consuming which, if not properly handled, might cause a memory blast.
The solution seems to be the serialization/deserialization of objects into/from temp files. It is better having a slow ill app than having a quick dead.
Thanks for the feedback.
Bunburry
|
|
|
|
|
how come the data is not processed right when it's received ? don't answer, just thinking out loud...
If your application is not speed dependant, I'd store the incoming data on disk right away, and only keep in memory the "file names", and when the data need to be processed, load it back from disk.
The problem with that, is that if the amount of data "received" in the house objects is really small compared to the overhead of having it on file; you'll still have the same memory problem.
Bunburry wrote:
It is better having a slow ill app than having a quick dead.
Well, it's better to have a healty running app than and slow and ill one!
Max.
|
|
|
|
|
Bunburry wrote:
The pointers really point to some house made objects which are generated from a serial flow of data and then "consumed" by the app.
I would use memory mapped files!
Store your data in a memory mapped file. That will allow you to access any part of the memory buffer as if it were a pointer (because it is loaded into memory), yet at the same time it is persisted to your harddrive. Therefore if you do not consume the data immediately it can be stored to disk.
The only issue here is that you will need to manage the memory in the file in such a way that will allow you to flag the ranges of memory that have and have not yet been consumed.
Bunburry wrote:
It is better having a slow ill app than having a quick dead.
Basically it is best to shoot for a healthy app. Once you get a basic design set forth that is healthy, you can always improve the speed later. The speed can come from eliminating processing that isnt necessary, or moving items to back ground threads and processes. Get your solution working first, then increase the speed later.
Build a man a fire, and he will be warm for a day Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Besides all thoses problems, it's not possible to have a garbage-collector working with it.
LPCTSTR Dutch = TEXT("Double Dutch ");
|
|
|
|
|
You wont need a garbage collector, you will simply need a small class to manage the stream pointers for each of the data pieces. I have used a memory mapped file in a number of projects for interprocess communication where I managed data streams in both directions.
In this particular instance, the data would be copied to the memory mapped file, and if the data should be stored to disk, the virtual memory pages will just need to be flushed to the disk and it is instantaneously saved.
Build a man a fire, and he will be warm for a day Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Paul Watt wrote:
You wont need a garbage collector, you will simply need a small class to manage the stream pointers for each of the data pieces. I have used a memory mapped file in a number of projects for interprocess communication where I managed data streams in both directions.
I didn't make my point clear enough, I meant if you're using a Garbage Collector, the pointers move around, if you save the pointer to a file, you must explicitly lock the pointer, if not, the ponter is read but doesn't point to the right address.
Sjoerd van Leent
LPCTSTR Dutch = TEXT("Double Dutch ");
|
|
|
|
|
hello @all,
i have a mdi program. in the mainframe you have for example:
File -> Close
i would like to hide 'Close' to the users until the correct password entered.
enter password:
View -> Password
the 'Close' should not be gray or something like that. the user should not see that there is something like the 'Close', until he enter the right password.
i hope you can help me.
(please, give me an example or explain it in detail)
thank you very much
MFC
|
|
|
|
|
What you want to do is BAD UI!
If the user start your application and cannot close it until he enters a password, it's offensive ! user still can kill the application ...
But I will give you a hint:
Check for CMenu::DeleteMenu ...
Anyway, I suggest you review your application workflow.
Max.
|
|
|
|
|
thanks for reply.
the 'Close' is only an example.....sorry.....you are right.
can you help me more?
mfc
|
|
|
|
|
MFC is the Best wrote:
the 'Close' is only an example.....sorry.....you are right.
can you help me more?
In what way ? Design ? Code ?
I don't know exactly what you intend to do ? so this is highly speculative :
If your application needs a password, it should be asked at the beginning, in a modal dialog, upon return of that dialog, if the password is wrong, you have the choice to either continue ( and you need to be able to check whether the password is valid or exists to block most operations with the ON_UPDATE_COMMAND_UI messages for menus and other type of check ) or quit.
If you continue running the application, you need a menu item to allow the user to enter the password.
Max.
|
|
|
|
|
Hello,
I need the definitions for the following constants:
SPDRP_DEVTYPE
SPDRP_ADDRESS
SPDRP_BUSNUMBER
SPDRP_BUSTYPEGUID
SPDRP_CAPABILITIES
SPDRP_CHARACTERISTICS
SPDRP_CLASS
SPDRP_CLASSGUID
SPDRP_COMPATIBLEIDS
SPDRP_CONFIGFLAGS
SPDRP_DEVICEDESC
etc... (all constants SPDRP_*)
Please, I know that these constants are defined in a SDK or DDK, I don't need this SDK/DDK! I just need the definitions of the constants which begin with SPDRP_.
I don't need the descriptions of the constants, but their definitions, like
#define SPDRP_DEVTYPE ...
Thanks in advance!
-Dominik
|
|
|
|
|
#define SPDRP_DEVICEDESC (0x00000000) // DeviceDesc (R/W)
#define SPDRP_HARDWAREID (0x00000001) // HardwareID (R/W)
#define SPDRP_COMPATIBLEIDS (0x00000002) // CompatibleIDs (R/W)
#define SPDRP_UNUSED0 (0x00000003) // unused
#define SPDRP_SERVICE (0x00000004) // Service (R/W)
#define SPDRP_UNUSED1 (0x00000005) // unused
#define SPDRP_UNUSED2 (0x00000006) // unused
#define SPDRP_CLASS (0x00000007) // Class (R--tied to ClassGUID)
#define SPDRP_CLASSGUID (0x00000008) // ClassGUID (R/W)
#define SPDRP_DRIVER (0x00000009) // Driver (R/W)
#define SPDRP_CONFIGFLAGS (0x0000000A) // ConfigFlags (R/W)
#define SPDRP_MFG (0x0000000B) // Mfg (R/W)
#define SPDRP_FRIENDLYNAME (0x0000000C) // FriendlyName (R/W)
#define SPDRP_LOCATION_INFORMATION (0x0000000D) // LocationInformation (R/W)
#define SPDRP_PHYSICAL_DEVICE_OBJECT_NAME (0x0000000E) // PhysicalDeviceObjectName (R)
#define SPDRP_CAPABILITIES (0x0000000F) // Capabilities (R)
#define SPDRP_UI_NUMBER (0x00000010) // UiNumber (R)
#define SPDRP_UPPERFILTERS (0x00000011) // UpperFilters (R/W)
#define SPDRP_LOWERFILTERS (0x00000012) // LowerFilters (R/W)
#define SPDRP_BUSTYPEGUID (0x00000013) // BusTypeGUID (R)
#define SPDRP_LEGACYBUSTYPE (0x00000014) // LegacyBusType (R)
#define SPDRP_BUSNUMBER (0x00000015) // BusNumber (R)
#define SPDRP_ENUMERATOR_NAME (0x00000016) // Enumerator Name (R)
#define SPDRP_SECURITY (0x00000017) // Security (R/W, binary form)
#define SPDRP_SECURITY_SDS (0x00000018) // Security (W, SDS form)
#define SPDRP_DEVTYPE (0x00000019) // Device Type (R/W)
#define SPDRP_EXCLUSIVE (0x0000001A) // Device is exclusive-access (R/W)
#define SPDRP_CHARACTERISTICS (0x0000001B) // Device Characteristics (R/W)
#define SPDRP_ADDRESS (0x0000001C) // Device Address (R)
#define SPDRP_UI_NUMBER_DESC_FORMAT (0X0000001D) // UiNumberDescFormat (R/W)
#define SPDRP_DEVICE_POWER_DATA (0x0000001E) // Device Power Data (R)
#define SPDRP_REMOVAL_POLICY (0x0000001F) // Removal Policy (R)
#define SPDRP_REMOVAL_POLICY_HW_DEFAULT (0x00000020) // Hardware Removal Policy (R)
#define SPDRP_REMOVAL_POLICY_OVERRIDE (0x00000021) // Removal Policy Override (RW)
#define SPDRP_INSTALL_STATE (0x00000022) // Device Install State (R)
#define SPDRP_LOCATION_PATHS (0x00000023) // Device Location Paths (R)
#define SPDRP_MAXIMUM_PROPERTY (0x00000024) // Upper bound on ordinals
#define SPCRP_SECURITY (0x00000017) // Security (R/W, binary form)
#define SPCRP_SECURITY_SDS (0x00000018) // Security (W, SDS form)
#define SPCRP_DEVTYPE (0x00000019) // Device Type (R/W)
#define SPCRP_EXCLUSIVE (0x0000001A) // Device is exclusive-access (R/W)
#define SPCRP_CHARACTERISTICS (0x0000001B) // Device Characteristics (R/W)
#define SPCRP_MAXIMUM_PROPERTY (0x0000001C) // Upper bound on ordinals
hope this helps
Gruß
modified 12-Sep-18 21:01pm.
|
|
|
|
|
|
Hi !!
I want to convert text file into image file (jpg or tiff or gif) and save it. Can anyone tell me how ???
Thanks in advance.
|
|
|
|
|
You need to draw it yourself. Create a bitmap, and then draw the text on it. If you want to save in something other than bmp you need something like CXImage, GDI+ or Paintlib. I have lots of GDI+ articles on CP, and CXImage also lives here.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
You will need to load it into memory, then render it to a bitmap. You can do that by creating a bitmap and a memory device context then render the text with the DrawText API.
After that you can save it out. There is no default mechanism to save JPG or GIF files in the Win32 API so you will need to use the LibJPEG or some other libraries in order to save your image.
Good Luck
Build a man a fire, and he will be warm for a day Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Hello,
I'm finishing one program that must be the interface to work with a machine, that program gets started automatically from a service.
I need to be able to make my app appear even over the taskbar.
Do you know how to do it?
NOTE:
this->ShowWindow(SW_SHOWMAXIMIZED);
is not working for me...
|
|
|
|
|
this seems to work on 2k.. not sure if its exactly what you want but I jus threw this into a dialog and it worked as expected.
CRect pRect;
GetDesktopWindow()->GetWindowRect(pRect);
MoveWindow(pRect);
Rob
|
|
|
|
|
or if you dont want it maximized just have the ability to be moved over the top of the start bar..
SetWindowPos(&wndTopMost,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE );
Rob
|
|
|
|
|
This is a bit, but it shows how to create a full-screen view like VC++ and MS-WORD. If you need an explanation on how it works I can post the rest. But this is what you need to make it work.
Step 1. Add two Boolean member variables to your main application window class
<code>class CMainFrame : public CMDIFrameWnd
{
protected:
BOOL m_bFullScreen;
BOOL m_bWasZoomed;
};</code>
Step 2. Add code to the constructor of your main application window class to initialize to FALSE the member variables added in step 1:
<code>CMainFrame::CMainFrame()
{
m_bFullScreen = FALSE;
m_bWasZoomed = FALSE;
}</code>
Step 3. Add the "View, Full Screen" menu command to all your menu resources. Because this command is handled by the main application window, it should always be available whatever the currently active document or view type. Optionally add a toolbar button for the "View, Full Screen" command.
Step 4. Use ClassWizard to add an 0N_COMMAND handler in your main application window class for the "View, Full Screen" menu command. Use ClassWizard again to add a handler for the WM_GETMINMAXINFO message to your main application window class. Implement these handlers as shown below. Note that these two functions work in coordination to achieve the desired behavior.
<code>void CmainFrame::OnViewFullScreen()
{
int cyCaption = ::GetSystemMetrics( SM_CYCAPTION );
int cxFrame = ::GetSystemMetrics( SM_CXFRAME );
int cyFrame = ::GetSystemMetrics( SM_CYFRAME );
int cxScreen = ::GetSystemMetrics( SM_CXSCREEN );
int cyScreen = ::GetSystemMetrics( SM_CYSCREEN );
int cyMenu = ::GetSystemMetrics( SM_CYMENU );
m_bFullScreen = ! m_bFullScreen;
if( m_bFullScreen )
{
m_bWasZoomed = IsZoomed();
if( m_bWasZoomed )
{
SetWindowPos( NULL,
-cxFrame,
-( cyFrame + cyCaption + cyMenu ),
cxScreen + 2 * cxFrame,
cyScreen + 2 * cyFrame + cyCaption + cyMenu,
SWP_NOZORDER );
}
else
{
ShowWindow( SW_SHOWMAXIMIZED );
}
}
else
{
if( m_bWasZoomed )
{
SetWindowPos( NULL,
-cxFrame, -cyFrame,
cxScreen+2*cxFrame,
cyScreen+2*cyFrame,
SWP_NOZORDER );
}
else
{
ShowWindow( SW_RESTORE );
}
}
}
void CmainFrame::OnGetMinMaxInfo(MINMAXINFO FAR* lpMMI)
{
int cyCaption = ::GetSystemMetrics( SM_CYCAPTION );
int cxFrame = ::GetSystemMetrics( SM_CXFRAME );
int cyFrame = ::GetSystemMetrics( SM_CYFRAME );
int cxScreen = ::GetSystemMetrics( SM_CXSCREEN );
int cyScreen = ::GetSystemMetrics( SM_CYSCREEN );
int cyMenu = ::GetSystemMetrics( SM_CYMENU );
CFrameWnd::OngetMinMaxInfo( lpMMI );
if( m_bFullScreen )
{
lpMMI->ptMaxPosition.y = -( cyFrame+cyCaption+cyMenu );
lpMMI->ptMaxSize.y = lpMMI->ptMaxTrackSize.y =
cyScreen+2*cyFrame+ cyCaption+cyMenu;
}
else
{
lpMMI->ptMaxPosition.y = -cyFrame;
lpMMI->ptMaxSize.y = lpMMI->ptMaxTrackSize.y = cyScreen+2*cyFrame;
}
lpMMI->ptMaxPosition.x = -cxFrame;
lpMMI->ptMaxSize.x = lpMMI->ptMaxTrackSize.x = cxScreen+2*cxFrame;
}</code>
At this point, your application already supports the full-screen view. However, you may wish to add a nice touch to the implementation by helping the user get back from the full-screen view to normal mode by simply pressing the Escape key. To do this, follow these additional steps:
Step 5. Create a new resource symbol called (for example) ID_VIEW_BACK_TO_NORMAL. (Click "View, Resource Symbols" click the New button.)
Step 6. Use ClassWizard to add an ON_COMMAND handler in your main application window class for the ID_VIEW_BACK_TO_NORMAL symbol that you defined in step 5. Implement this handler.
<code>void CmainFrame::OnViewBackToNormal()
{
if( m_bFullScreen )
{
OnViewFullScreen();
}
}</code>
Step 7. Edit your IDR_MAINFRAME accelerator table to define a new accelerator entry that associates the Escape key with the ID_VIEW_BACK_TO_NORMAL symbol that you created in step 5.
|
|
|
|
|
I am looking for a way to do a 3 state item similar to the 3 state check box. My boss doesn't like the way that the 3 state checkbox looks and wants me to find an alternative. I havn't seen anything here so far but I probably missed something. I'd appreciate any help.
Thanks,
Amy
|
|
|
|
|
Funny how easily some people say they don't like something but yet don't offer an alternative. I would tell your boss that unless he knows of an alternative, that a 3-state checkbox is the way to go. It's a standard Windows behavior:
Checked on White = all of the options are selected
Checked on Gray = some options are selected, some aren't
Not Checked = none of the options are selected
I've seen this type of checkbox in installation programs more than anything else. How are you planning on using yours?
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
It will be used as a binary toggle, either it is 1, 0, or neither. He likes how it works he just thinks that when it is in the neither(gray) state it looks too much like the ones that are disabled. There are a few places where it will be mixed in with disabled options. Visually it is difficult to tell the difference until you click on it.
Amy
|
|
|
|
|
The only alternative I can think of is radio buttons. They occupy more space but they should definitely clear things up on your dialog box:
Do you like this? O Yes O No O Dunno
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|