Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
grey image on itemEnabled
Hello there,
we recently updated our srp controls and we are having an issue with the shortcut bar. whenever we set ItemEnabled to 0 the ItemImage goes to grey with nothing in it.
in the attached image you can see the first two items enabled and using the same icon the next three are disabled.
we would appreciate your help in this matter.
we recently updated our srp controls and we are having an issue with the shortcut bar. whenever we set ItemEnabled to 0 the ItemImage goes to grey with nothing in it.
in the attached image you can see the first two items enabled and using the same icon the next three are disabled.
we would appreciate your help in this matter.
Comments
I have forgotten to mention that we are doing this on 64bit system. Would it be possible to provide us with the 64bit build of your fix?
However, I now can't seem to enter in any (enterable) EDLs in my forms now.
In my quick play it seems to be an issue on Form Open.
Edit Tables are still accessible, as are Checkboxes, Radio Buttons, Options (Dropdowns, Calendar, etc)
It seems once I have triggered an Event from a working Control I seem to have acces to my EDLs again.
Close down and restart OpenInsight. Same symptoms.
Close down. Revert (register) to previous SRPControls.ocx. Start up. Symptoms gone.
Any ideas @KevinFournier?
Running Form from MDI with SRP RIBBON control.
Have to wait a while before you can use the mouse to move between fields.
You CAN [TAB] between fields, so therefore, they are NOT disabled.
If you close the MDI and run the form from the form designer, the 'mousing' works immediately.
@BarryStevens is correct.
I opened the form and went away and did something else. Came back and the form was fully accessible with no other intervention...
if you launch MDI Ribbon menu for the first time (OI9.4.6) the ribbon tooltips do not respond while hovering over the ribbon until you click on an icon.
For some backstory, I had made a change to the Ribbon control some months ago that I thought was clever but has only since created more problems. In OI 10, under the hood, each form has a single child control called a FrameClient control, and all the OI controls live on that child control. This is great for the Ribbon control in OI 10 because I can easily make room for the ribbon by simply resizing the FrameClient control and letting OI take care of resizing all the child controls accordingly.
OI 9 has no such FrameClient control, so in my cleverness, I decided to make my own. Starting in 4.2.2.2 of the SRP Controls, the Ribbon control secretly creates a new OI form outside of the presentation server, moves all the OI controls to that form, and viola, I’ve got a little borderless OI form resizing all the controls for me with pixel perfect accuracy. Fully automated. No need to ask devs to do anything extra.
Then the forum messages started coming in. Modal dialog boxes were leaving the form disabled. MSG boxes were not returning values. Now, as noted above, edit lines are not responding to mouse messages. As it turns out, OI 9 is very inconsistent with how it finds the parent of a control. Instead of using the equivalent of the PARENT property, they would travel up the hierarchy utilizing different assumptions each time. Sometimes, the immediate parent was assumed (which was a problem since I changed the control's parent) and sometimes they would assume that the parent was the topmost non-child form (which was a problem when re-enabling MDI child forms after a dialog box).
Unwilling to admit defeat, I created work arounds to address these problems, but the unresponsive edit lines could not be fixed with gum and hanger wire. I had to admit that my clever secret client form was breaking the presentation server’s rigid ecosystem. This update completely undoes all my clever work and returns it back to the days before SRP Controls 4.2.2.
The problem with the old days is that child controls don’t line up very nicely when using themes. The Ribbon likes to alter caption and border sizes, and the presentation server is unaware of these alterations. To compensate, this release adds the LayoutChildControl method to the Ribbon. You can use it to basically transfer sizing and positioning to the Ribbon, taking it out of OI’s hands completely. This seemed to be the best way to get pixel perfect positioning with compromising the integrity of the presentation server.
So, on the one hand, I've solved the editline issue. On the other hand, I've given you some additional homework. Again, you do not need the above method in OI 10.
Have you not watched MacGyver? If thats enough for him to build a rustic nuclear device then.... ;-P
I will add this to my list.
Homework. I almost feel like I am back in school!
*shivers*
I ended up copying in the example code as is to my FW_MAIN Create event as all the controls and everything were named appropriately.
It seems to have 'fixed' another issue I have noticed with the 4.2.x series Controls in that my Statusbar is now visible. By this I mean it was always there, just hidden behind the Windows status bar (we open our OI app full screen)
However, and this is the bit I find curious, that only seems to have worked because I also included a
Set_Property(@Window:".OLE_RIBBON", "OLE.Theme"...) line.
If I dont include that line, my Statusbar 'hides' again. If I only add that line, the Statusbar remains hidden. When I have both the OLE.LayoutChildControl and the OLE.Theme code together I get the Statusbar back!
Not complaining but can you explain that @KevinFournier?