Specifiying twice LWA_COLORKEY in Win32 API - c++

I'm trying to find a way to be able to replace 2 COLORS on a specific Window (which isn't made by me, it's another problem).
LONG ExtendedStyle = GetWindowLong(handle,GWL_EXSTYLE );
SetWindowLong(handle,GWL_EXSTYLE,ExtendedStyle | WS_EX_LAYERED );
::SetLayeredWindowAttributes(handle,RGB(251,254,249),0,LWA_COLORKEY);
This works well, now I'm trying to call twice:
::SetLayeredWindowAttributes(handle,RGB(251,254,249),0,LWA_COLORKEY);
with a different color code
LONG ExtendedStyle = GetWindowLong(handle,GWL_EXSTYLE );
SetWindowLong(handle,GWL_EXSTYLE,ExtendedStyle | WS_EX_LAYERED );
::SetLayeredWindowAttributes(handle,RGB(251,254,249),0,LWA_COLORKEY);
::SetLayeredWindowAttributes(handle,RGB(251,254,220),0,LWA_COLORKEY);
This does NOT work and only the last one is taken into account, I've searched extensively and wish to not go into too advanced solutions as my problem seems simple. Anyone has a clue?
EDIT: I'm sorry I'm very unfamiliar with this API and I have a client that requires me to replace 2 colors (or more) in a window, I'm already losing way too much time on this. Your help is very very welcome. Thank you

According to the document of SetLayeredWindowAttributes function, if you use a parameter LWA_COLORKEY, all areas of the form where the color is crKey will become transparent and the bAlpha parameter is invalid. So only the last function is valid. If you want to make multiple areas transparent, you can set them to the same color in advance.

Related

Why doesn`t Cosos2d ClippingNode work properly?

I try to use ClippingNode for my Cocos2d project, but due to some unknown reason it doesn`t work the proper way neither on Iphone, nor Android. Here is the code being used. The stencil is Label with string "7". Are there any mistakes or is it simply a Cocos2d problem?
auto colors = Sprite::create("colors.png");
colors->setContentSize(Size(nodeSize.width * 1.25, nodeSize.height * 1.25));
colors->setPosition(recordNumLbl->getPosition());
colors->setName("recordNum");
auto cropNode = ClippingNode::create(recordNumLbl);
cropNode->setGlobalZOrder(11);
cropNode->setName("cropNode");
cropNode->addChild(colors);
this->addChild(cropNode);
You can see the result I get on the first image, and what I try to get on the second one. Any help is highly appreciated!
https://i.stack.imgur.com/fZ9LX.png
https://i.stack.imgur.com/xH1hp.png
The global Z value needs to be exactly the same for any children of a clipping node. So, for the example you posted, you would need to set this:
colors->setGlobalZOrder(11);
Also, make sure the stencil you use (recordNumLbl?) is also set to a global Z of 11.

Owner-draw with CTabCtrl using MFC

Using VS 2015. I have a dialog-based app (NOT a PropertySheet), and have a CTabCtrl-derived object in which I want to disable specific tabs. From what I've googled, owner-draw is the way to go. Fine, can understand that.
What I would like to do is START with an owner-drawn version that acts exactly like the non-owner-drawn version, and then start tweaking it variously to experiment. For example, I'd like to use things like
void CTabControl::DrawItem( LPDRAWITEMSTRUCT lpDrawItemStruct )
{
CTabCtrl::DrawItem( lpDrawItemStruct ); // do exactly what unmodified does
}
so that I am basically calling everything the unmodified CTabCtrl would do to accomplish the drawing. Even the simplest starting point would be helpful. What routines do I need to override or intercept to do this?
I'm setting TCS_OWNERDRAWFIXED in PreSubclassWindow() and doing what I showed above, and one or two other things, but the result definitely doesn't look the same. For one thing, no text in the tabs.
I'd really love it if I could get some pointers on where to start. BTW, I'm creating the control programatically (no dialog resources) like this (CTabControl inherits from CTabCtrl):
MyDlg::OnInitDialog()
{
...
m_tabctrl = new CTabControl();
m_tabctrl->Create( TCS_TABS | TCS_BOTTOM | TCS_HOTTRACK | TCS_FIXEDWIDTH | WS_CHILD | WS_VISIBLE, dummyRect, this, ID_TABCTRL );
...
}

Reordering MFC control IDs automatically

I've got a pretty old MFC application that's been touched by many people over the years (most of them probably not even CS guys) and it follows, what I like to call the "anarchy design pattern."
Anyway, one of the dialogs has a series of 56 vertical sliders and check boxes. However, there are additional sliders and checkboxes on the dialog as shown below.
Now, the problem is that the additional sliders and checkboxes take on IDs that are in sequence with the slider/checkbox series of the dialog. My task is to add more sliders and checkboxes to the series (in the blank space in the Slider Control group box) Unfortunately, since IDC_SLIDER57 through IDC_SLIDER61 are already in the dialog (same goes for the checkboxes), existing code, such as the snippet below will break:
pVSlider = (CSliderCtrl *)GetDlgItem(IDC_SLIDER1+i);
Is there a better way to modify the resource file without doing it manually? I've seen a third party tool called ResOrg that looks like it'll help do what I want, but the software is a bit pricey, especially since I'll only use it once. I guess I can give the demo a try, but the limitations might restrict me.
FYI, I'm using Visual C++ 6.0 (yes...I know, don't laugh, it's being forced upon me).
Instead of writing:
pVSlider = (CSliderCtrl *)GetDlgItem(IDC_SLIDER1+i);
you could write:
pVSlider = (CSliderCtrl *)GetDlgItem(GetSliderID(i));
where GetSlider is a function that returns the id of slider number i.
GetSlider function
int GetSliderID(int nslider)
{
static int sliderids[] = {IDC_SLIDER1, IDC_SLIDER2, IDC_SLIDER3, .... IDC_SLIDERn};
ASSERT(nslider < _countof(sliderids));
return sliderids[nslider];
}
With this method the IDC_SLIDERn symbols dont need to have sequential values.

XLib - Window hints behave differently when I construct XWindowAttributes in the main function?

I am experimenting with some fundamental Xlib stuff. I am creating a basic window and creating an OpenGL context for it.
I am trying to prevent the user from being able to resize or manually full screen the window. I added the code:
XSizeHints hints;
hints.min_width = hints.max_width = setup.w;
hints.min_height = hints.max_height = setup.h;
XSetWMNormalHints(dpy, win, &hints);
This worked at first. However after experimenting with it I have found that it mysteriously stops working sometimes. It is not a matter of unusual window managers or anything like that, I am using the default windows manager installed with Ubuntu. What causes it to change, strangly enough, is whether or not I include this line in main:
XWindowAttributes atts;
It does not matter where I put it. At the beginning, or inside a loop, or even after the return. As long as I put that somewhere in main the hints prevent resizing (just to be clear, any name for the variable works). It does not matter if I use it at all or not, it was initially there for a call to XGetWindowAttributes. I discovered the problem when I tried moving that into a separate function call. If I take it out, the window will have a full screen button and I will be able to shrink it. I have experimented with declaring the variable other places, such as in the struct where I contain the Window and GLXContext.
What is going on here? The way I see it I either have a very subtle and unusual bug coming from my virtual machine or something weird like that, or I have missed some obvious piece of information. Can anyone shed some light on this?
Well, I have no explanation for why declaring a XWindowAttributes instance in main was making it work, but I did figure out what was wrong with my code and I was able to make it behave as expected when I made the following changes:
Do not create XSizeHints directly as shown above. Create it as follows:
XSizeHints *hints = XAllocSizeHints();
Set flags in the object specifying which variables are used:
hints->flags = PMinSize|PMaxSize;
Use XSetWMNormalHints and XSetWMSizeHints:
XSetWMNormalHints(dpy, win, hints);
XSetWMSizeHints(dpy, win, hints, PMinSize|PMaxSize);
I also put a pointer to the hints in my struct containing data about the window. All together the code above became:
XSizeHints *hints = wind->hints = XAllocSizeHints();
hints->flags = PMinSize|PMaxSize;
hints->min_width = hints->max_width = setup.w;
hints->min_height = hints->max_height = setup.h;
XSetWMNormalHints(dpy, win, hints);
XSetWMSizeHints(dpy, win, hints, PMinSize|PMaxSize);
For those that came here:
1. Communicating with the Windows Manager
It's all about convention like said at 12.3 in the "Xlib Programming Manual VOL1". Some WM will completely ignore hints like max & min size, because eg they manage Windows as Tiled Windows. So, how YOUR Window Manager will get your choices is an issue.
2. Make things in the right order.
This will perhaps answer your question : "What is going on here?"
Most difficulties with X comes from the order you make things. I encountered the same trouble as yours, and solve it because I saw I didn't follow the right process.
Chapter 12.3.1 from the "Xlib Prog Manual" says:
'Once the client has created the windows, BUT BEFORE IT MAPS THEM, it must place properties to help WM manage them effectively'
In your case, it means you cannot use XSetWM* functions AFTER your window is mapped. Some properties will have an effect, some others not, and sometimes some will be overridden with bad values.
3. The right order. (AFAIK)
a. Set an Error Handler
b. Get a Display
c. Init your Context (here GLX) & get a Visual from it.
d. set Window Attributes (events mask, ...)
e. Create your Window
e. Set WM Properties (eg your sizehints, min/max size, class, title, ...)
e.1 always init pointers you need with XAlloc* when possible
e.2 use X11r4 XSetWMProperties that will put them all at once, avoid use of deprecated functions.
e.3 XFree your 'pointers'
f. Set the Wm Protocols you are interested in (WM_DELETE_WINDOW, ...)
g. set some others properties according to your needs (eg _NET_WM_PID, ...)
h. Finally, Map your Window
4. See what happens : use xprop
xprop will report how your window is known by your Windows Manager.
If your size hints were properly set, you will see some lines like:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 550, 200
user specified size: 500 by 500
program specified minimum size: 500 by 500
program specified maximum size: 65535 by 65535
Hope it helps future users,
(PS: the previous answer TS#Oct 27 '14 at 15:26 has an error: XSetWMSizeHints expect an Atom as 3rd arg.).

wxPython - how to colour the text of a statusbar

I searched for the answer in the forum, but I didn't find anything, if I am wrong, I am sorry.
Anyway, question is simple, I have this Frame, with a Status Bar I use to print messages or notifies.
I would like to use it for mistakes or not permitted operations. But I would like these messages to be coloured. I am looking for a solution on wxPython demo -because i read somewhere on the web to get some inspirations by it-, but i still did not find anything.
Do you have any ideas or solutions?
thank you in advance.
I would try the SetForegroundColour or SetBackgroundColour methods of the status bar widget. These methods don't always work on every platform though as each OS has its own rules and wxPython follows those rules. If they do not work, then you'll have to roll your own statusbar, probably by using a couple of panels in a sizer or a splitter window.
There is also the 3rd party EnhancedStatusbar widget which might work for you. It can be found at http://xoomer.virgilio.it/infinity77/main/EnhancedStatusBar.html
Simple solution: pin wx.StaticText on the status bar and write text in it. Text coloring in wx.StaticText works well.
For example:
self.sb = self.ws.CreateStatusBar()
self.sbtext = wx.StaticText(self.sb, -1, '', pos=(8, 4))
...
self.sbtext.SetForegroundColour(wx.Colour(color))
self.sbtext.SetLabel(text)