RichEdit.Height = MainForm.ClientHeight - 22 SetWindowLong(Application.Handle, GWL_HWNDPARENT, MainForm.Handle)ĬomboBox.AddItems(" Item #0 "," Item #1 ") SetWindowLong(MainForm.Handle, GWL_HWNDPARENT, HWND_DESKTOP) Hint = "Edit Operations."&CHR$(10)&"Cut,Copy,Paste,Delete" Hint = "File Operations."&CHR$(10)&"Open,Save,Clear,Exit" Top = (Screen.Height\2)-(MainForm.Height\2) Left = (Screen.Width\2)-(MainForm.Width\2) ' a subroutine to pop all the QCoolBtns up. 'The QForm has an event to capture the hint message ' the QCoolBtn's to pop back up after being clicked 'Well it's the simplest and easiest way to get ' and why do they not have the ShowHint property. ' why do the QPanel, QComboBox, and QRichEdit (ByVal hWnd As Long, ByVal nIndex As Long, _ĭeclare Sub MainForm_OnHint(sHint As String)ĭeclare Sub File_OnClick(Sender As QMenuItem)ĭeclare Sub Edit_OnClick(Sender As QMenuItem)ĭeclare Sub ComboBox_OnChange(Sender As QComboBox) (replace rqb with whatever extension works for you) The easiest way to explain what I mean is John is certainly right, but I am not able to distinguish the mainmenu system message from the form. But I can open each the menuitems going through the main menu which must open them, and at that moment causes the problem. Warnig, the handle changes only in menuitems. Because the Form and its MAINMENU are the same thing. So If I am working over the MAINMENU the event of the mouse SOMETIMES is captured by the form. Instead the mainmenu has the same class (it is not children) of the QForm.
System messages addressed to them NEVER disturb the form If I check the buttons, or the panels, or each menu item, they have their class and their handle. I don't know if I managed to explain myself better. In fact the problem seems solved if I use Popmenu and not mainmenu, part of the form. This also in response to David (many thanks): I have no problem with panel or button children or menuitems. It only reaches childrens and does not disturb the form. In fact with all the other childrens of the form the message has no problems. I think that if I block messages to the form, the mainmenu also stops working. I am not able to distinguish them (mainmenu and mainform). The mainmenus lights up and opens the menuitems (child) because it is also a feature of the form. When sometimes the problem occours, the mainform has the problem because the message to "show" the MAINMENU is a message relating exactly the form. The problem is not about the click of a particular menitem.
#Rapidq compiler version 9 0 upgrade windows
But all seems wroteĪt the end of the onmenu sub, where xxxxx is the windows messageID you want to stop going to opengl?yes it seems a good idea, but what message id I must trap? Now i'm finishing drawing exactly MainMenu emulation, using PopMenu, it's easy but it's long operation. With MainMenu I couldn't, because Onmouse is not read.
Then, when the operation is finished (Yes or Cancel), I restart the timer and the shape starts spinning again as it should. So, I when open the Popmenu, I can to stop the timer. Sometimes I had to click twice.īut I understand why! The trouble was the timer that call the OpenGL redraw! With PopMenu I had another problem, but I understood this immediately. OpenGL increase the risk which is in fact occasional.Īnyway using the PopMenu instead of Qmainmenu, the OpenGLdo not interfere. I am beginning to understand that the problem is the lack of synchronism, already present in RapidQ (fortunately there is Doevents!). (yes the shape does not disappear, it goes away) The "reset view point" is useful for this reason.
#Rapidq compiler version 9 0 upgrade code
Then following my code even if it's not directed at them, they move the shape out of the Form. Yes, the OpenGL exactly feel the movement of the mouse on the menu. T seems better to me, now I will adjust the 0,0,0 of the vectors of the normals calculating them on all the generated files, even if ASCII (and therefore boring to convert).Īnd I want to prepare an accurate INFO feature in the menus, to examine the files. MeshLabs adjusts the consistency between the face vector and the order of its points, as per convention.īut 3Dmods does not, if there is an error the shape remains dark gray (like OpenGL does). I did not understand why some STLs generated by me were read well, with shadows, on MeshLab, and instead opaque in dark gray on 3Dmods. Then, a new feature, but I hadn't written it, LOL. Lighter source, easier debugging, easier reading and understanding, and, important, reduction of possible future errors for obsolete windows functionalities. It contains only the necessary for OpenGL and it is a extract of Rapidq2.inc with addition of John (Thanks!) code interface between OpenGL and RapidQ. A important changing in the *.inc concept.
0 kommentar(er)
