I am creating a WC_COMBOBOXEX on Windows Vista and adding strings to it, but they don't show up in the control. The same strings show up fine if I use the old WC_COMBOBOX with CB_ADDSTRING.
I am calling InitCommonControlsEx with ICC_USEREX_CLASSES and creating the comboboxex using CreateWindowEx with style WS_CHILD|WS_CLIPSIBLINGS|CBS_SIMPLE|CBS_SORT|CBS_HASSTRINGS (no extended styles). I am adding the strings using
COMBOBOXEXITEM cbem = {0};
cbem.mask = CBEIF_TEXT;
cbem.iItem = -1;
cbem.pszText = L"hello";
SendMessage(hWnd_, CBEM_INSERTITEM, 0, TOLPARAM(&cbem));
The combobox comes up empty but when I move the cursor up and down in the editcontrol/listbox, I see funny block characters sometimes.
Eventually, I want to add it as a CBS_DROPDOWNLIST to a rebar control but I read somewhere that comboboxex works a lot better in there than the old combobox.
Thanks.
From MSDN:
ComboBoxEx controls support only the following ComboBox styles:
CBS_SIMPLE
CBS_DROPDOWN
CBS_DROPDOWNLIST
WS_CHILD
So CBS_SORT and CBS_HASSTRINGS may be messing up the style bits.
Does it help if you send CBEM_SETUNICODEFORMAT?
Related
I am trying to remove the underline from the items in my list box when i select it. I tried giving the entire list box the "activestyle=None" but i learned that you need to use the "itemconfigure". What i am lost on is what i should be putting for index. I have my .insert index as 'end' and it works properly but when i do that for the item configure it says its out of range. Here is the code if anyone can assist me here.
taskList = Listbox(setBox, bg="#1B2834",fg="white")
taskList.configure(width=183,height=39, activestyle=None, fg="#4299E9", selectbackground="#061523",
selectforeground="#4299E9")
taskList.itemconfigure('end', activestyle=None)
taskList.insert('end', taskIDnum)
You don't use itemconfigure to set the activestyle attribute. You should use the configure method of the listbox. The documented value to turn off the ring around active item (or underline, depending on platform) is the string "none", not the python value None.
taskList.configure(activestyle="none")
from pywinauto.application import Application
app = Application().Start(cmd_line=u'"path to program" ')
afx = app[u'Afx:01360000:0']
afx.Wait('ready')
afxtoolbar = afx[u'1']
toolbar_button = afxtoolbar.Button(3)
toolbar_button.Click()
window = app.Dialog
window.Wait('ready')
edit = window.Edit4
edit.Click()
app.typekeys ("Success")
So at this point, I've gotten the application to open, the correct window to pop up and also a mouse click on the box that I want to populate with a short string. I cannot for the life of me, figure out how to pass keyboard input to this field. I have read all the docs for PyWinAuto, and nothing is helping...
Basically all I need to do is figure out how to send a string, and then how to send the TAB key six times. I can then finish my program to automate this application.
I am also using Swapy64bit to help. The program uses a win32 backend. I'm using Python 3.6.
Am I not prefixing typekeys correctly? The PyWinAuto documentation leaves much to be desired.
First the correct name of the method is type_keys, but assume you use it correctly.
The reason might be losing focus at the edit control because type_keys tries to set focus automatically. The solution is:
app.type_keys("Success{TAB 6}", set_foreground=True)
As the title says, the height of my tabs is not increasing as it should, my code looks like this:
JTabbedPane jtp = new JTabbedPane();
JLabel iconInTab = new JLabel(new ImageIcon("myImage.png"));
iconInTab.setPreferredSize(new Dimension(100,80)); // is the size of my Image, I've also try to do this using getSize
jtp.addTab(null,new JPanel());
jtp.setTabComponentAt(0,iconInTab);
I've also try this using html but it did not work either:
jtp.addTab("<html><p><p><p></html>",new ImageIcon("myImage.png"),new JPanel());
with the first code the problem is not the change of the size horizontally (the width change correctly), the problem is only on the height, with the second code, if I add multiple lines inside the html code, the text appear incomplete (just show the middle line) (also the width behaves as expected, the problem is the height). . .
why is this happening? or how could I get this done?
Note: S.O.: Mac OS X 10.8.1
Solved!!! The problem was that the default UI over MAC OS X (com.apple.laf.AquaTabbedPaneContrastUI), you only need to change it to the basicTabbedPaneUI (or the one of your preference), in my particular case I need to extend this class (it was a pain in the *, because what I wanted was really complex) to get the look & feel that I was expecting, if you have the same trouble just do this before adding your tabs:
myTabbedPane.setUI(new BasicTabbedPaneUI());
Note: Checking the default UI of your TabbedPane, may solve many different problems.
I was trying to copy an image to the clipboard and paste it into gimp with this code snippet:
BufferedImage bi = new BufferedImage(board.getAmount()*16,16,BufferedImage.TYPE_INT_ARGB);
Graphics2D g2d = bi.createGraphics();
Color[] colors = board.getColors();
for (int loop = 0; loop < board.getAmount(); loop++) {
g2d.setColor(colors[loop]);
g2d.fill(new Rectangle(16*loop,0,16,16));
}
ImageSelection is = new ImageSelection(bi);
Toolkit.getDefaultToolkit().getSystemClipboard().setContents(is, null);
Anyways in theory everything should have worked out fine. It gave me no errors, but when I try to paste the image, nothing happens.
This was done on two different linux machines and neither worked. I then came to school and tried it out with the same code on Windows and it worked.
So I guess my real question is does it have something to do with open-jdk, or java 1.7, or is it linux's problem? And how can I fix it?
I think the next page could be useful: http://www.java2s.com/Code/Java/2D-Graphics-GUI/SendingImageObjectsthroughtheClipboard.htm.
Consider the following lines to copy the image to the clipboard.
final Clipboard clipboard = frame.getToolkit().getSystemClipboard();
label.setTransferHandler(new ImageSelection());
...
TransferHandler handler = label.getTransferHandler();
handler.exportToClipboard(label, clipboard, TransferHandler.COPY);
I had the same problem, and found this to work:
final Clipboard clipboard = frame.getToolkit().getSystemSelection();
...then continue using that as a regular clipboard. The "system selection" allows you to change what the window manager thinks is selected, and is therefore "on the clipboard".
I'm not sure what the best way to detect whether system selection or system clipboard should be used, but it looks like Windows will return null for getSystemSelection, so that can be used as a test.
I'm using MFC's doc/view architecture to implement printing. I use double buffering, I draw everything onto my backbuffer which is DIB bitmap. Than I use StretchBlt to copy that DIB onto printer DC.
The strange thing is - print preview is working well! When I print on virtual PDF printer, it is working well! But when I print on actual printer (I'm testing on two different printers - same results) - it just prints "garbage". The "garbage" means sometimes it prints totally black page, sometimes it prints the first few pages repeatedly, i.e. it prints wrong part of DIB, just like if I messed up coordinates to StretchBlt, but I didn't mess anything up, I checked multiple times, plus why is print preview is working flawlessly then?
I tried many variations:
Using memory DC compatible to screen DC, when printing.
Using memory DC compatible to printer DC, and selecting my DIB into it.
Using memory DC compatible to printer DC, and using dedicated DIB onto which I copy my original backbuffer DIB.
etc.
But the results are same. Below is the code where i create the DIB. I think the DIB format might be the problem, so please advice if there is something wrong with it. I tried both 24 bits and 32 bits as values for bmiHeader.biBitCount.
// Setup proper backbuffer:
_CleanupBackBufferStuff();
_pMemDc = new CDC;
_pMemDc->CreateCompatibleDC(&aDC);
BITMAPINFO bmi;
memset(&bmi, 0, sizeof(BITMAPINFO));
bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
bmi.bmiHeader.biWidth = _sizeBackBuffer.cx;
bmi.bmiHeader.biHeight = -_sizeBackBuffer.cy; // top-down
bmi.bmiHeader.biPlanes = 1;
bmi.bmiHeader.biBitCount = 24; // Tried 32 as well
bmi.bmiHeader.biCompression = BI_RGB;
unsigned char *pBitmapRawBits = 0;
HANDLE hMemBitmap = CreateDIBSection(aDC.GetSafeHdc(), &bmi, DIB_RGB_COLORS, (void**)&pBitmapRawBits, 0, 0);
_hOldSelBitmap = (HBITMAP)_pMemDc->SelectObject(hMemBitmap);
Also here is the code for StretchBlt (nothing special here):
pDC->SetStretchBltMode(HALFTONE);
SetBrushOrgEx(pDC->GetSafeHdc(), 0, 0, 0);
BOOL bSuccess = pDC->StretchBlt(rectClipBoxPlayground.left, rectClipBoxPlayground.top, rectClipBoxPlayground.Width(), rectClipBoxPlayground.Height(),
_pMemDc, rectClipBoxBackBuffer.left, rectClipBoxBackBuffer.top, rectClipBoxBackBuffer.Width(), rectClipBoxBackBuffer.Height(), SRCCOPY);
StretchBlt returns true, also (pDC->GetDeviceCaps(RASTERCAPS) & RC_STRETCHBLT) is true as well.
UPDATE: After Adrian's comment, I changed my code to use StretchDIBits. The problem is still the same! Below is the code I'm using currently:
// Copy back buffer to screen dc:
pDC->SetStretchBltMode(HALFTONE);
SetBrushOrgEx(pDC->GetSafeHdc(), 0, 0, 0);
HBITMAP hMemBitmap = (HBITMAP)_pMemDc->SelectObject(_hOldSelBitmap);
DWORD dwLines = StretchDIBits(pDC->GetSafeHdc(),
rectClipBoxPlayground.left, rectClipBoxPlayground.top, rectClipBoxPlayground.Width(), rectClipBoxPlayground.Height(),
rectClipBoxBackBuffer.left, _sizeBackBuffer.cy - rectClipBoxBackBuffer.top - rectClipBoxBackBuffer.Height(), rectClipBoxBackBuffer.Width(), rectClipBoxBackBuffer.Height(),
_pBitmapRawBits, &_bitmapInfo, DIB_RGB_COLORS, SRCCOPY);
_pMemDc->SelectObject(hMemBitmap);
It still behaives like the source coordinates are incorrect. It either prints one of first few pages (no matter what page I select), or prints almost-fully-black pages. The print preview is working perfectly, so this makes me think there should be no problems with my coordinate-calculation code. It works in preview, it works with virtual (pdf) printer, it fails when printing on actual printer. What the hell?....
Make sure you don't have the DIBSECTION selected into more than one DC at a time. That can cause all sorts of unpredictable behavior.
For printing, you can probably bypass the memory DC altogether if you keep your bmi and pBitmapRawBits handy. Make sure the DIBSECTION is not selected into any DC, and then call SetDIBitsToDevice or StretchDIBits to transfer the image to the printer DC.
If you're still having problems, you might want to check the capabilities of your printers. Not all the drivers support all the bitmap transfer methods. I believe the printing system is supposed to hide those differences from you, but perhaps not. Call GetDeviceCaps on your printer DC, and check the RASTERCAPS for RC_BITBLT and friends.