Transparency in images

[Fred Tomke]

Hello,

I use backcolor for menuitems. But unfortunately it does not work anymore but I do know that it worked in earlier releases (5.0.2.4, 5.1.0.2).
I attached a sample to demonstrate.

When the mouse will be moved over a menuitem (a text and 3 images within a frame) that background shall be colored. Although the three images ob the right are transparent they're still showing the backcolor of the form.

How must I change the code to update the images that they're showing the control behind?

Fred

[Fred Tomke]

Hm, I could fence the problem:

before calling the command HOVER of the sample place the mouse on the screen where a menuitem will be shown. Call the command then. If the form appears, the menuitem under the mouse cursor is shown with the correct backcolor, otherwise with the wrong. See the attached images.

Fred

[owenwengerd]

Picture Box controls cache a copy of what is initially displayed on the screen, then repaint the control by simply copying from the cache. When you change the background, you have to refresh the cached copy by calling (dcl_PictureBox_Refresh).

What has changed recently is that the cache is now used all the time. In the past, the cache was used only after certain function calls. That inconsistency caused some unexpected behavior (see the bug tracker).

[Fred Tomke]

Hello Owen,

I'm not really glad with it. I added a newer lsp-file for testing. Moving the mouse over the menuitems the layout behaves unexpected.

Fred

[owenwengerd]

I guess you mean the text disappears? I can't reproduce that here, but any time you have overlapping controls the repainting order is more or less random, so this is not surprising. Have you considered drawing your text and pictures directly onto a single picture box for each menu item?

[Fred Tomke]

Hello Owen,

Have you considered drawing your text and pictures directly onto a single picture box for each menu item?

I hope I understand you right but I think I have done so.
You see one single picture in the back: the whole colored area is one single picture box.
Onto the background picture there is one label at left hand side then a source picture, then an arrow and on the right hand side the result picture.

These 4 controls in front of the background picture are using backcolor -24. In this test I only tried to switch the visibility of the background picture and I had to refresh the controls in front of it.

I also had another test. I switched the visibility of the background picture AND the backcolor of the 4 controls in front of the background picture between red (if mouseover) and -16 (if mouseoff). This worked very well and was much more performant than using transparent pictures. But going back to change the backcolor of all controls of one menuitem should not be the goal of transparent controls, I think.

Fred

[owenwengerd]

You misunderstood what I meant. I meant to eliminate your overlapping controls so that there is only a single control for each menu item.

[Fred Tomke]

I cannot imagine what this could be. If I delete the background image it is very difficult to highlight the whole menuitem. Am I wrong, when I thought that transparent controls are introduced for overlapping? A fixed text on an image for instance.

Fred

[owenwengerd]

I've posted before that Windows does not support overlapping controls, according to Microsoft. The problems that have been discussed here before are the reason why it is not supported -- because Windows has no mechanism for guaranteeing that they are painted in the correct order.

Overlapping controls work fine in cases where neither control does any painting at the same locations. For example, text inside a frame results in the text control and the frame control overlapping, however neither paints in the same location so the end result looks fine.

So, to answer your question, transparent controls are designed to allow the form background to show through. It may work with overlapping controls in some specific cases, but it does not work in general when controls overlap.

In your case, there is no need for overlapping controls, so the problem can be solved by removing all controls except the background picture box, and drawing everything on the background picture box.

[Fred Tomke]

Aaaah, now I got it - you mean using PaintPicture and DrawWrappedText.
I must say, I've never used it before. I will give it a try.

Fred

[Fred Tomke]

Hi, Owen

I had a test. It works quite fine. I can switch between backcolors -16 and red, but not between -24 and read. It seems that it won't get updated after setting backcolor -24. Is there anything I missed to do?

Code (autolisp) Select Expand

(defun hover (intMethode / intItem oControl)
    (foreach intItem (vl-remove intMethode '(1 2 3 4 5 6))
      (setq oControl (eval (read (strcat "gis1_sc_overlay_pic_" (itoa intItem)))))
      (if (/= (dcl_Control_GetBackColor oControl) -24)
(progn
  (dcl_Control_SetBackColor oControl -24)
); progn
      ); if
    ); foreach
   
    (if (and intMethode (setq oControl (eval (read (strcat "gis1_sc_overlay_pic_" (itoa intMethode)))))
     (/= (dcl_Control_GetBackColor oControl) 12040191))
      (progn
(dcl_Control_SetBackColor oControl 12040191)
      ); progn
    ); if
  ); hover

Fred

I attached the sample.

[owenwengerd]

This is now fixed for beta 2 (and it works very well now -- good job!).

[Fred Tomke]

Hello Owen,

yes, this looks nice, but unfortunately all of the forms which includes picture boxes with a default image (set in the editor), the images in the picture boxes are not shown anymore even if the content of the picture box won't be changed at runtime. These pictureboxes will stay empty.

The attachment shows an area with 3 fixed images behind each radio button which are not changed at runtime. In 5.1.1.2 they are not shown anymore.

Fred

[owenwengerd]

I introduced a new bug in Beta 2 that causes the picture to be deleted the first time it's refreshed. This is now fixed for Beta 3.