In some references, I have found that white box testing is sometimes called glass box testing. I would like to know what are the reasons behind that.
Black Box Testing: You can not peek inside the box (i.e. the code), all you know is the interface/API of the system under test
White Box Testing: You can peek inside the box. White, because it is the "oposite" of black. I have not heard of Glass Box Testing before, but it actually makes sense, because it emphasizes the "you can peek inside" notion.
Related
So I'm creating an application using SFML, which I want to be borderless, so no border style. I added the ability to move it around on the screen and am planning on adding the ability to scale the window, however, that made me realise there's just a bit more to this. When dragging any window (not mine) say to the top of the screen, windows kicks in and suggests the ability to scale it to full, or when you drag a window to the side of the screen windows, again, kicks in and suggests making it cover half your screen. And it does this on borderless applications like Google chrome, or Spotify as well. I could probably try and add this in myself, but it's obvious other applications dont implement it themselves as you can see windows actually doing it the way it visually shows it. So, how would I go ahead imlementing this? I'm using SFML 2.5.1 with C++.
I have tried looking through google and stackoverflow to see if anyone has had any similar issues, of which I couldn't find any, which could honestly have been me not knowing how exactly to phrase it.
I’m a big fan of Firefox’s mini grid view in the web inspector, which provides
a small version of the currently overlaid grid, which is in proportion to the real thing.
Hovering over the different areas of the mini grid causes the equivalent area on the grid overlay to also highlight, along with a tooltip containing useful information such as the dimensions of that area, its row and column numbers, etc. [my emphasis]
It bugs me to no end, though, that the tooltip emphasised in the quote does not appear if the highlighted grid row/column is too close to the viewport’s edge. Instead of adjusting for this by moving the tooltip into view, the behaviour seems to be just to not show it at all, which rather defeats the purpose – especially when, as far as I know, this tooltip is the only way to see the calculated size of empty grid tracks.
I can’t find any bugs regarding this on Bugzilla, but then I can virtually never find anything on there, so there’s a decent chance I’m just bad at searching.
Is there some setting I can’t find that will allow me to see the tooltips even for edge rows/columns? Or if this is just a bug, has it been addressed?
I've tested this in Firefox 98.0 and could reproduce it. As this is definitely a bug in the Firefox DevTools and I couldn't find one either in Bugzilla, I now created a bug report for it.
Inside the rectangle I placed slicers.
Clicking on the uncovered part of the rectangle moves it in front of the visualizations making them unavailable to interact with, or hidden.
I "Send to back" rectangle but it didnt help.
The visuals are on a picture below:
But if I just hoover mouse on a rectangle area - it covers all visuals:
Any solution to just always keep re
Yeah, that's pretty annoying. I'd suggest voting for this idea and maybe Microsoft will fix this eventually.
Currently, the only workaround I can think of would be to make the colored rectangle part of the page background as an image.
I'm currently using Google Chrome as my main browser. I wondered how the developers put the custom titlebar, because I wanted to incorporate into one of my own applications.
If you guys don't know what I'm talking about, here's a picture:
I found an article about the interface, which is here:http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/33870516-9868-48d3-ab53-6269d9979598
However, I don't know how to do this. I'm currently using VC++ Express. Can anyone give me step by step instructions and how to get an interface like that? Except I don't want tabs on top.
I'm writing this in Win32.
If memory serves, the main things you need to handle aren't WM_NCCALCSIZE, but WM_NCHITTEST and WM_NCPAINT.
WM_NCHITTEST is what tells the system when the cursor is over the title bar, so you need to take a cursor position and decide whether it's over the area you consider "title bar". In particular, if the user clicks and drags with the cursor in this area, the whole window gets dragged.
WM_NCPAINT is just like WM_PAINT except for the non-client area -- i.e., this is when you need to actually draw whatever you're going to for the title bar (and window borders, if memory serves).
I should add that I haven't played with this in quite a while. There's almost certainly more I'm not remembering right now.
OK, the answer is simple:
Chomre simply does not use the Windows built in functionality for drawing a frame border, titlebar, titlebar buttons, etc..
When you call GetWindowRect(hChromeWindow) and GetClientRect(hChromeWindow) you will notice that the rectangles are identical. This means that Chrome turns off all Windows functionality for drawing a border (simply return 0 in WM_NCCALSIZE without doing anything else) and then they draw EVERYTHING into the client area.
So in WM_PAINT they draw the titlebar and the upper part of the window (URL bar, tabs, etc..) together. In WM_NCPAINT they do nothing.
This is not the common way to do it, but the easiest, and it is bullet-proof.
By the way: Java applications do the same.
I'm trying to implement some drag and drop functionality for a material system being developed at my work. Part of this system includes a 'Material Library' which acts as a repository, divided into groups, of saved materials on the user's hard drive.
As part of some UI polish, I was hoping to implement a 'highlight' type feature. When dragging and dropping, windows that you can legally drop a material onto will very subtly change color to improve feedback to the user that this is a valid action.
I am changing the bar with 'Basic Materials' (Just a CWnd with a CStatic) from having a medium gray background when unhighlighed to a blue background when hovered over. It all works well, the OnDragEnter and OnDragExit messages seem robust and set a flag indicating the highlight status. Then in OnCtrlColor I do this:
if (!m_bHighlighted) {
pDC->FillSolidRect(0, 0, m_SizeX, kGroupHeaderHeight, kBackgroundColour);
}
else {
pDC->FillSolidRect(0, 0, m_SizeX, kGroupHeaderHeight, kHighlightedBackgroundColour);
}
However, as you can see in the screenshot, the painting 'glitches' below the dragged object, leaving the original gray in place. It looks really ugly and basically spoils the whole effect.
Is there any way I can get around this?
Remote debugging is a godsend for debugging visual issues. It's a pain to set up, but having a VM ready for remote debugging will pay off for sure.
What I like to do is set a ton of breakpoints in my paint handling, as well as in the framework paint code itself. This allows you to effectively "freeze frame" the painting without borking it up by flipping into devenv. This way you can get the true picture of who's painting in what order, and where you've got the chance to break in a fill that rect the way you need to.
It almost looks like the CStatic doesn't know that it needs to repaint itself, so the background color of the draggable object is left behind. Maybe try to invalidate the CStatic, and see if that helps at all?
Thanks for the answers guys, ajryan, you seem to always come up with help for my questions so extra thanks.
Thankfully this time the answer was fairly straightforward....
ImageList_DragShowNolock(FALSE);
m_pDragDropTargetWnd->SendMessage(WM_USER_DRAG_DROP_OBJECT_DRAG_ENTER, (WPARAM)pDragDropObject, (LPARAM)(&dragDropPoint));
ImageList_DragShowNolock(TRUE);
This turns off the drawing of the dragged image, then sends a message to the window being entered to repaint in a highlighted state, then finally redraws the drag image over the top. Seems to have done the trick.