|
Assuming you are talking about a CEdit control, you can use the SetFont[^] method.
|
|
|
|
|
yes you are correct any examples for that one...
|
|
|
|
|
Probably plenty if you go and search. However, it is not really too difficult to create a CFont object and use that as shown in the documentation.
|
|
|
|
|
A bit of History
These days it is quite simple. A lot of the complication about fonts arose during the 1990's, the Font Wars. Various companies claimed copyright over their named fonts. That is absolutely No problems if the fonts you use are on the same computer that you write your software on, Your Computer. Difficulties arise however, if you write a document in a set of fonts, try to load and print it on another computer, which may not have a Font installed by the same Name. Microsoft tried to resolve the issue, by trying to get the Closest Comparable Font. and included a structure which contains obscure Font designer Lingo terms, such as 'Internal Kerning'.
That War was won by Microsoft, Fonts can now be downloaded for free.
Things have simplified by now. Just specify Type Name, Style (Straight/Italic/Bold) and a Point Size. That is all that is required these days.
Regards
Bram van Kampen
|
|
|
|
|
steganography source code in c
|
|
|
|
|
Member 11443861 wrote: steganography source code in c What about entering that into the input field of your favorite search engine?
|
|
|
|
|
|
We have a many articles on steganography, here at Code Project.
|
|
|
|
|
Hello all,
I need a little help: I want to create an application that automatize different applications in the sense that my application will be able to press automatically different buttons on another application.
For example: my application will start, let's say, Microsoft Office, will press some buttons in MSOffice, and will close MSOffice.
Could you give me an idea how to do that ? I have no clue... some code in C/C++ would be perfect.
Thank you very much!
<script src="//www.codeproject.com:8011/bar17428.js" type="text/javascript" ></script>
|
|
|
|
|
|
In addition to sending the exact keys directly as Richard described (I think that method is basically replicating what a keyboard would do if I'm not mistaken), there is another way of achieving this. Sending messages to the application's control directly. Windows allows this and it's relatively easy to get the controls' ID's to send messages to them.
Use Spy++[^] to get control IDs and you can also intercept some messages to figure out how yours should be formatted.
Once you have control IDs, you can send messages using the SendMessage()[^] method.
Biggest problem with this method is that it's more of a hack than anything else. The control IDs are not guaranteed to be the same from one version of the software to the next.
|
|
|
|
|
Dear Friends,
Am developing a client server application. Am using MFC MDI. It has multiple class. One class is showing live values so i used Editbox and CListCtrl control. I was create these control in
onCreate() function. It shows live in
onDraw() function
GetDlgItem(IDC_EDITBOX)->SetWindowText(sLiveValues); it is also updating a value but it is getting flicker. If i use
InvalidateRect() function it is not flickering but not update any value. So i need to update live value in any control like EditBox,CListCtrl without flicker. How to avoid flickering. Please help me.
|
|
|
|
|
If I understand you correctly, you are calling SetWindowText() from onDraw(). This is a problem, because SetWindowText() invokes drawing of the control. So your apllication is permanently redrawing its GUI.
I would suggest that you store the values in the receiving function in a thread-safe way (look for CRITICAL_SECTION in the documentation). Then create a timer (look for SetTimer()) and in the timer function again in a thread-safe way copy the data to a local variable and display the copy with SetWindowText(). The OnTimer function could look something like this:
void YourDialog::OnTimer(UINT nIDEvent)
{
if (nIDEvent == YourTimerId)
{
EnterCriticalSection(&yourCriticalSection);
CString values = sLiveValues;
LeaveCriticalSection(&yourCriticalSection);
GetDlgItem(IDC_EDITBOX)->SetWindowText(values);
}
}
You can run the timer in any interval convenient for your users.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Hi,
I have a Dialog based Application. The Dialog may be Maximised. The Dialog is divided in three panes. There is a Dlg Wide reporting Section at the bottom, The Top is vertically divided in two, the LH Pane shows a Tree Control, The LH Pane shows further details of the selected node.
The divisions between the panes must be 'User Draggable'. What MFC control is available (if any) to capture the mouse, and perform the dragging action.
Regards,.
Bram
Bram van Kampen
|
|
|
|
|
|
|
I'm trying to create a set that stores vertices where vertices are defined by this class:
Quote: class Vertex
{
public:
Vertex();
~Vertex();
Vertex(double x_set, double y_set, double z_set, int bezierInd);
double x,y,z;
int bezierIndex;
bool operator<(const Vertex& rhs);
bool operator==(const Vertex& rhs);
bool operator!=(const Vertex& rhs);
};
I don't really know if i need a an allocator, but compile errors tell me I do. Also do I need a custom comparator? I created this one :
Quote: struct vertexCmp {
bool operator()(const Vertex& a, const Vertex& b) const {
return a.bezierIndex < b.bezierIndex;
}
};
and I'm creating a set like this :
set<Vertex, vertexCmp> bezierPoints;
|
|
|
|
|
You don't need a custom allocator for that type (or frankly, any type - effectively).
Custom allocators are a way to speed things up, or to keep data localized (definitely not mutually exclusive goals).
You DO however definitely need custom comparator functions, and you are close to getting it right. Very close. Have you considered making the member comparators const themselves, e.g. "bool operator<(const Vertex& rhs) const;"?.
++luck;
|
|
|
|
|
I do not understand why is the pointer address changing everytime during the output for a code while I am executing the same code?
The code:
int main()
{
int a;
a=100;
int *b;
b= &a;
printf("The address of a is %p\n", b);
return 0;
}
The gcc compiler output:
nikhil@nikhil-Lenovo-Product:~/Desktop$ ./a.out
The address of a is 0x7fff990d2f24
nikhil@nikhil-Lenovo-Product:~/Desktop$ ./a.out
The address of a is 0x7fffcec94eb4
nikhil@nikhil-Lenovo-Product:~/Desktop$ ./a.out
The address of a is 0x7fff70b595e4
nikhil@nikhil-Lenovo-Product:~/Desktop$
|
|
|
|
|
This is not raleted to C but on how executable programs are loaded into memory. Each time you start the program it is loaded into previously free memory space. The free memory space and possible start adresses are changing because there are also other tasks and programs allocating and freeing memory.
|
|
|
|
|
In addition to what already told you have to consider that the variable whose address you are watching is a local automatic variable that resides on the stack that is is even more variable.
|
|
|
|
|
That is not quite correct, since each process uses its own address space, and memory addresses within a program do not correspond to physical memory addresses. The system memory manager instead creates a virtual memory address space for each process and maps that space onto the actual physical addresses. These addresses may change, specifically when some of that virtual memory exceeds the physical memory available.
Therefore, theoretically, the system memory manager could guarantee to always provide the same memory pointer upon repeated runs of a program. However, the memory manager is written to be efficient, not consistent between runs. I'm not that much into the inner workings of system memory managers, but I suspect that - depending on the current address space mappings - they will try to place allocations in regions of continuous physical memory to minimize the time they need searching. These regions will vary for the reasons you mentioned: other services and programs that are also using (and releasing) memory.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Hi Stefan,
Mike Nordell below gave a probable correct answer in that it is most likely due to ASLR. We don't know for sure since the original poster did not include OS version. Many modern operating systems are implementing this now including Linux.
My suggestion for the original poster is to recompile his project with /DYNAMICBASE[^] disabled. If he gets the same result after recompiling with /DYNAMICBASE disabled then he should check if Force ASLR[^] is enabled. (I am assuming he is on Windows and compiling with gcc within Cygwin based on his shell prompt)
Best Wishes,
-David Delaune
|
|
|
|
|
Maybe ASLR is the answer. But I see a lot of open questions. For one, my understanding of ASLR is that it will only randomize the memory address of the code area, and that area is separate from both the stack and the heap areas. Second, even if ASLR does also randomize the physical address of the stack or heap areas, will that have an effect on data addresses within an application? AFAIK it should not! If that were true, how could memory virtualization work? Third, I've seen data addresses both stay the same and change to different values on restarting an application (the same application, without changes to the code), implying that the address modifications are not deliberate.
But as I said, I do not know the internals of the Windows memory manager. Maybe ASLR does have a subtle (possibly unintended) side effect that influences data memory addresses within the application.
Anyway, I see very little use in querying data addresses. They do not directly correspond to physical addresses, they can and will be affected by changes in the code, and they will likely be different on different machines, even if they can be made to stay conatant on the same machine. The only thing I use data addresses for is setting data breakpoints - and I try to avoid those normally since they tend to eat a lot of performance.
P.S.: I've just checked the Wiki Article on ASLR[^] which was a bit more informative than the ones you linked to: apparently, in Windows, the ASLR implementation does randomize stack and heap addresses too. The physical addresses, mind you. That doesn't explain variations of the virtual addresses visible within the application though.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
modified 13-Feb-15 3:21am.
|
|
|
|
|
Most likely ASLR - Address Space Layout Randomization.
The operating system is trying to help you not get pwnd due to easily exploitable crappy code.
|
|
|
|