|
I have loaded a bitmap to a dialog.
But that bitmap contains white background and it looks odd in the dialog.
I need to match bitmaps background with dialogs menu (grey) color.
How to do this?
|
|
|
|
|
|
The technical word for Making bitmap background invisible is MASKING...
if ur using white color as Bitmap background then
Use below function to change it to backGround color
ColorTo( RGB(white),RGB(BkGroundColor));
Search in an MSDN for this concept and also follow the code
// Create a Bitmap object from an image file
Bitmap myBitmap = new Bitmap("Grapes.gif");
// Draw myBitmap to the screen
e.Graphics.DrawImage(
myBitmap,
0,
0,
myBitmap.Width,
myBitmap.Height);
// Get the color of a background pixel
Color backColor = myBitmap.GetPixel(1, 1);
// Make backColor transparent for myBitmap
myBitmap.MakeTransparent(backColor);
// Draw the transparent bitmap to the screen
e.Graphics.DrawImage(
myBitmap,
myBitmap.Width,
0,
myBitmap.Width,
myBitmap.Height);
|
|
|
|
|
|
I am writing a structure of 20 bytes in to a file. Whenever I run the application I want to capture the last set written into the file. I used SeektoEnd () but of no use. How can I capture the last set (all 20 bytes of the structure) from the file?
|
|
|
|
|
i think i you open that in binary type, you should be able to do CFile::Seek(-20, CFile::end);
|
|
|
|
|
jasmine_123 wrote: How can I capture the last set (all 20 bytes of the structure) from the file?
FileObj.Seek( -20, CFile::end );
FileObj.Read(...);
|
|
|
|
|
Hi,
How do I find the 'Country Code'(or Localisation Code) of a Computer that my software tries to run on. As part of DOS 6.00 a long list of Country and Language Codes was published by Microsoft. I assume that these codes are still valid. I issue User Licences for my Software, and want to place geographical restrictions on the licence.
Regards, 
Bram van Kampen
|
|
|
|
|
this might be a starter - http://www.lingoport.com/gi/help/gihelp/unsafeMethod/winlocalefunc.htm[^] see in-particular ...
"GEOID
GEOID is the Win32 geography identifier that defines the country or location where the user lives. It is only supported on Windows XP, Windows Server 2003, and Windows ME (though not Windows 2K). The setting can be changed via the Regional Options tab of the Regional And Language Options property sheet."
(There may be an equivalent for W2K, I havnt seen it yet)
Have you also thought about matching up their public tcp/ip address to one of those services that know where the endpoint is located ?
(My thoughts are that the locale, and yes, even the TCP/IP address may be changed, so you may need one or two methods to be able to determine location)
'g'
|
|
|
|
|
Exelent! Exactly what I was looking for. The matching of TCP/IP addresses has one problem, my software does not require an internet connection. (the software is for essentially a Cash Register).
The Software is currently not being licenced for use outside the UK and Ireland, but, if somebody in France wants to circumvent this by switching locale, on their heads be it! For Now, I jiust want to check for the English(UK) locale.
Many Thanks, 
Bram van Kampen
|
|
|
|
|
Hi,
Your reply gave me a massive number of links, and my problem is Sorted. The documentation and tests about GEOID however suggests that it will not work until GEOID is set by a User App. (Smart thinking Mr Gates, New Feature, Let all users fill in the details over time)
What suits me for now is to determine the Lanmguage, and the Time Zone.
Just for your own reference,
Regards,
Bram van Kampen
|
|
|
|
|
Hi,
I want to be able to dynamically load a library dynamically. Easy right? Just use LoadLibrary(). The problem is that I want to be able to load the library into separate memory spaces each time (e.g. I don't want each loading instance to share the same global variables). Calling LoadLibrary() twice within the same process just returns you back the same handle.
Any help would be greatly appreciated.
Thanks.
|
|
|
|
|
You don't. Trying to load a DLL that's already present simply ups a reference count.
Steve
|
|
|
|
|
Seems like you need to put those variables in class.
-Saurabh
|
|
|
|
|
Just not possible in this case. There's no way to 'manage' this as it is used by thousands of function calls in a very large legacy application (over a million lines of code).
|
|
|
|
|
Hi,
Look at your concepts again. You're trying to do something that is 'Funamentally Disallowed'. My advise is: re-appraise the basic concept of your program. You probably need to stick your current global data in a small database.
Bram van Kampen
|
|
|
|
|
Sorry that's just not really helpful. I'm already aware that the design is not ideal, unfortunately I'm dealing with a very large legacy application in which if the variable in question were dynamic (a handle to an ISAM db) I would have to pass the handle to thousands of function calls. It's just not feasible and that's why I'm looking for another solution.
|
|
|
|
|
How is it the problem arises now?
How could the legacy system run fine for that long a time?
What has changed?
|
|
|
|
|
The problem has never arisen before because before now every loaded instance of the application has only ever had to log in once to a single database.
Now we need to be able to log in and have open multiple handles to a database.
|
|
|
|
|
sludgenz wrote: Sorry that's just not really helpful.
Nevertheless true.
Steve
|
|
|
|
|
The first solution to your problem is obvious although I can understand perhaps not very palatable: update the DLL so it doesn’t use globals. The second solution which springs to mind is to get a different process to host the DLL for you and your main EXE would communicate to different instances of the DLLs via the host processes.
Steve
|
|
|
|
|
Yep, I had considered that solution and it is probably the way I am going to go (although separate AppDomains within the same process is looking like a promising line of inquiry too).
Updating the DLL so that it doesn't use the global handle to a dataset is completely impractical, it's over a million lines of code, with 10s of thousands of function calls which would have to pass in the handle to a dataset, unless I wrap the entire application in a separate object somehow which also seems very impractical. I completely understand that loading the DLL into multiples instances in memory is an undesirable solution but it is the most desirable among the solutions that appear to be available (I'm talking with confidence here as an experienced programmer whose had other experienced programmers review the problem to make sure I'm not missing something)
The original design was a poor choice, agreed, but that was over 15 years ago and I certainly didn't make it.
Thanks for the help, based on the feedback I'm now pretty sure it's not possible.
|
|
|
|
|
sludgenz wrote: although separate AppDomains within the same process is looking like a promising line of inquiry too
Native code has no concept of AppDomains.
sludgenz wrote: I completely understand that loading the DLL into multiples instances in memory is an undesirable solution but it is the most desirable among the solutions that appear to be available
While technically it may be possible, it would be a daunting task to load multiple versions of a same DLL into different locations in the same process. Doing so would require re-implementing your own PE loader.
If I was going to use the “host the DLLs in a separate process” approach I’d use COM. When your local server calls CoRegisterClassObject[^] it would use the REGCLS_SINGLEUSE value of the REGCLS[^] enum to ensure each instance is in a separate process. Obviously you'd have to wrap the features you use from the DLL in COM interfaces.
Steve
|
|
|
|
|
Stephen Hewitt wrote: Native code has no concept of AppDomains.
Yes I know, but the process that actually loads the native .DLL is actually a .NET Windows Service (using interop to calll out to the native code).
Stephen Hewitt wrote: If I was going to use the “host the DLLs in a separate process” approach I’d use COM. When your local server calls CoRegisterClassObject[^] it would use the REGCLS_SINGLEUSE value of the REGCLS[^] enum to ensure each instance is in a separate process. Obviously you'd have to wrap the features you use from the DLL in COM interfaces.
I hadn't thought about using COM, thanks.
|
|
|
|
|
sludgenz wrote: Yes I know, but the process that actually loads the native .DLL is actually a .NET Windows Service (using interop to calll out to the native code).
The barriers between AppDomains are enforced when the MSIL is JITed and require the code to be verifiable. It will not help that the client is managed.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
