My application has two Pictures embedded in the Frame. My code is as follows:
wxMemoryInputStream istream1(Bild_png, sizeof Bild_png);
wxImage Bild_png(istream1, wxBITMAP_TYPE_PNG);
new wxStaticBitmap(p_img, wxID_ANY, wxBitmap(Bild_png));
vbox->Add(p_img ,0);
(vbox is the Sizer)
When I start the App, I've a "T-" at the left-upper corner in both Bitmaps. When I change the notebookitem("screen") and get back to the first Screen (where the Bitmaps are) the "-T" has disappeared...
How can I fixed it, so that I will never see the failure?
i had to call Layout() at the upmost sizer. That has solved my problem. It means at the end:
vbox->Layout()
#catalin, I don't think that to post aorund 2000 lines of sourcecode is a better way. I had choose this little snipped, because it says all what needed. A expert with wxWidgets had give me - with this four lines - the hint that something is fault with the sizer, not with the pic.
Haven't you been advised before to search the samples? For example widgets; just grep for wxStaticBitmap and I'm sure you'll find something useful.
This is just a poor way of asking a question.
In your c++ snippet you're using Bild_png even before it was declared - really? Then you mention both Bitmaps and notebookitem("screen") which are just unknown items to anyone else but you.
IMO it is just too... wrong to receive a good answer...
Related
I got point sprites working almost immediately, but I'm only stuck on one thing, they are rendered as probably 2x2 pixel sprites, which is not really very easy to see, especially if there's other motion. Now, I've tried tweaking all the variables, here's the code that probably works best:
void renderParticles()
{
for(int i = 0; i < particleCount; i ++)
{
particlePoints[i] += particleSpeeds[i];
}
void* data;
pParticleBuffer->Lock(0, particleCount*sizeof(PARTICLE_VERTEX), &data, NULL);
memcpy(data, particlePoints, sizeof(particlePoints));
pParticleBuffer->Unlock();
pd3dDevice->SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE);
pd3dDevice->SetRenderState(D3DRS_ZWRITEENABLE, TRUE);
pd3dDevice->SetRenderState(D3DRS_POINTSPRITEENABLE, TRUE);
pd3dDevice->SetRenderState(D3DRS_POINTSCALEENABLE, TRUE);
pd3dDevice->SetRenderState(D3DRS_POINTSIZE, (DWORD)1.0f);
//pd3dDevice->SetRenderState(D3DRS_POINTSIZE_MAX, (DWORD)9999.0f);
//pd3dDevice->SetRenderState(D3DRS_POINTSIZE_MIN, (DWORD)0.0f);
pd3dDevice->SetRenderState(D3DRS_POINTSCALE_A, (DWORD)0.0f);
pd3dDevice->SetRenderState(D3DRS_POINTSCALE_B, (DWORD)0.0f);
pd3dDevice->SetRenderState(D3DRS_POINTSCALE_C, (DWORD)1.0f);
pd3dDevice->SetStreamSource(0, pParticleBuffer, 0, sizeof(D3DXVECTOR3));
pd3dDevice->DrawPrimitive(D3DPT_POINTLIST, 0, particleCount);
pd3dDevice->SetRenderState(D3DRS_POINTSPRITEENABLE, FALSE);
pd3dDevice->SetRenderState(D3DRS_POINTSCALEENABLE, FALSE);
}
Ok, so when I change POINTSCALE_A and POINTSCALE_B, nothing really changes much, same for C. POINTSIZE also makes no difference. When I try to assign something to POINTSIZE_MAX and _MIN, no matter what I assign, it always stops the rendering of the sprites. I also tried setting POINTSIZE with POINTSCALEENABLE set to false, no luck there either.
This looks like something not many people who looked around found an answer to. An explanation of the mechanism exists on MSDN, while, yes, I did check stackoverflow and found a similar question with no answer. Another source only suggested seting the max and min variables, which as I said, are pretty much making my particles disappear.
ParticlePoints and particleSpeeds are D3DXVector3 arrays, and I get what I expect from them. A book I follow suggested I define a custom vertex with XYZ and diffuse but I see no reason for this to be honest, it just adds a lot more to a long list of declarations.
Any help is welcome, thanks in advance.
Edit: Further tweaking showed than when any of the scale values are above 0.99999997f (at least between that and 0.99999998f I see the effect), I get the tiny version, if I put them there or lower I pretty much get the size of the texture - though that is still not really that good as it may be large, and it pretty much fails the task of being controllable.
Glad to help :) My comment as an answer:
One more problem that I've seen is you float to dword cast. The official documentation suggests the following conversion *((DWORD*)&Variable (doc) to be put into SetRenderState. I'm not very familiar with C++, but I would assume that this makes a difference, because your cast sets a real dword, but the API expects a float in the dwords memory space.
I've used the following code to draw on a Image using a wxMemoryDC.
To do so I used a wxPen and changed the settings of the pen as in the following code. The code compiles and runs perfectly in windows environment. But in Ubuntu it draws the lines but the pen size stays correctly for a very little time and then the pen size becomes very low.(As shown in the image) It is not an error of the m_pensize variable because it always prints the correct value. Why does this works so strange in ubuntu when it works correctly in windows?.
(m_graphics is the memoryDC here)
if (x<m_backgroundImage.GetWidth() && y< m_backgroundImage.GetHeight()){
m_graphics.SelectObject(m_maskImage);
wxPen* pen;
if (m_isDrawing){
pen = wxThePenList->FindOrCreatePen(*wxRED, m_penSize);
printf("Pen size is %d", m_penSize);
}
else{
pen = wxThePenList->FindOrCreatePen(*wxBLACK, m_penSize);
}
if (m_pentype != Circle){
pen->SetCap(wxCAP_PROJECTING);
}
m_graphics.SetPen(*pen);
m_graphics.DrawLine(m_lastX,m_lastY,x,y);
m_graphics.SelectObject(wxNullBitmap);
}
In windows it is shown Correctly
In linux The pen size is changed unexpectadly.
Your help is greatly appreciated.
If the same code behaves differently in wxMSW and wxGTK, then it's probably a bug in wxWidgets itself, however to fix it it needs to be reproduced in some simple to test way, ideally by making the smallest possible change to the wxWidgets drawing sample and opening a ticket attaching this change as a patch to it.
To simplify the code as much as possible, I'd recommend:
Getting rid of wxThePenList and just creating the pen directly. It's unlikely that the bug is here, but who knows.
Check if it's not due to SetCap() call, this is the most likely candidate IMHO.
I cannot set text alignment correctly. For instance, if I do this, then bottom alignment gets lost
memDC.SetTextAlign(TA_BOTTOM);
memDC.SetTextAlign(TA_RIGHT);
memDC.TextOutW(textRect.left, textRect.top, _T("HELLo"));
And if I do this, then right alignment gets lost.
memDC.SetTextAlign(TA_RIGHT);
memDC.SetTextAlign(TA_BOTTOM);
memDC.TextOutW(textRect.left, textRect.top, _T("HELLo"));
There does not seem to exist a way to keep both alignments. Any suggestions to fix this?
They're bitflags:
memDC.SetTextAlign(TA_RIGHT | TA_BOTTOM);
I'm Having an issue with loading an image with devIL for openGL
in an earlier part of my project i call
ilInit();
in a function right after i call my load just like this
//generate a texture
ilGenImages( 1, &uiTextureHandle );
//bind our image
ilBindImage( uiTextureHandle );
//load
//ilLoad( IL_PNG, (const ILstring)"fake.png" );
ilLoad( IL_PNG, "fake.png" );
for the sake of error tracking i did place "ilGetError()" after every call
which returned 0 for all of these except for ilLoad which returns 1285
after some searching i figured out that this is a lack of memory error.
so ilLoad always returns 0 and not loaded.
anyone know what im doing incorrect as for my loading or if i forgot to do something
because i feel i might have forgotten something and thats the reason why 1285 appears.
A common reason for ilLoad() to fail with IL_OUT_OF_MEMORY is simply if the PNG file you're using is corrupt.
However, 1285 means IL_INVALID_VALUE - it means the path you're giving it is likely wrong. Try an absolute path (remembering that back slashes aren't okay in C++ unless you use double slashes).
I personally have used DevIL for quite some time and did like it. However, I urge you to consider FreeImage. It has a bit more development going on and is quite stable - I used it in a commercial engine for all my image needs, and it integrates decently well with DirectX/OpenGL much like DevIL.
I'm having a problem on Vista with the Listview control, in particular setting custom icons on the header. Normally under XP or any of the previous version of Windows, if I added an icon (in C++), I could do so with the following:
HeaderItem.mask = HDI_FORMAT | HDI_IMAGE;
Header_GetItem(HeaderHWND, Column, &HeaderItem);
TurnOn(HeaderItem.fmt, HDF_IMAGE);
HeaderItem.iImage = Image;
if (Header_SetItem(HeaderHWND, Column, &HeaderItem) == 0)
printf("Failed to set header [%d:%.8X]\n", GetLastError(), GetLastError());
and then to remove the image, on a particular column, I could use the same process but instead of turning on the HDF_IMAGE bit, you just turn it off.
On Vista, however, when I turn it off it doesn't seem to actually be accepting the change. So, for instance, when I start my fmt is:
0x4000 (or basically HDF_STRING)
I turn on the icon, and it becomes:
0x5800 (or basically HDF_STRING | HDF_IMAGE | HDF_BITMAP_ON_RIGHT)
I then turn it off again, but the result is:
0x4800 (or basically HDF_STRING | HDF_IMAGE)
I've checked, and I setting it to HDF_STRING only, but once HDF_IMAGE is set, it seems to be impossible to remove. Header_SetImage doesn't return any errors, so I'm at a loss as far as what to do. I've also tried removing the Imagelist from the control, but it still leaves the space as if there still was an image there.
At the end of the day I need to be able to add and remove icons from the header, and when they are removed I need all the header space available again (as they were before any were displayed. Any help would be greatly appreciated - thanks in advance!
If you read the documentation http://msdn.microsoft.com/en-us/library/bb775247(VS.85).aspx, if you indicate HDI_IMAGE in mask then iImage should be a valid index, you have to set it to I_IMAGENONE in order to remove it.
If you want to remve an image you have to do something like this:
HeaderItem.mask = HDI_FORMAT | HDI_IMAGE;
Header_GetItem(HeaderHWND, Column, &HeaderItem);
HeaderItem.fmt &= ~(HDF_IMAGE | HDF_BITMAP_ON_RIGHT);
HeaderItem.iImage = I_IMAGENONE;
Header_SetItem(HeaderHWND, Column, &HeaderItem);
Uhg, I just figured it out - they've changed slightly the way things work now as far as passed parameters.
Before, I always set the iImage to 0 when I was removing the HDF_IMAGE attribute - but it looks like now if you perform a Set, and your mask includes HDI_IMAGE, then it will not remove the HDF_IMAGE bit, even though you explicitly do.
So, the solution is to make sure not to send anything image-related if you're trying to remove it. Since I scoured the net and couldn't find anything about this, hopefully this post will now help anyone else who has a similar problem.