On Wed, 7 Oct 2015 01:50:04 +0200 Benoît Minisini <gam...@users.sourceforge.net> wrote:
> Le 06/10/2015 06:37, adamn...@gmail.com a écrit : > > I think this is way out there in the cosmos somewhere, but I'll ask > > anyway. > > > > I am wading through the FProperty code of the IDE trying to > > understand how the values for properties are set (bad term) in the > > grid. When I get down to CControl.GetProperty(sProp As String) I see > > the following (with annotations): > > > > Try hProp = Project.Documentation.Classes[Kind].Properties[sProp] > > > > If hProp Then If hProp.AlwaysRead Then <--- Question1 > > > > vVal = Object.GetProperty(Control, sProp) <---- Question 2 > > > > ... > > > > Endif Endif > > > > Return $cValue[sProp] <---- Question 3 > > > > 1) I see that these are set in the CPropertyInfo class but why are > > some properties AlwaysRead? > > Because property values are cached, and the real property value may > change without the cache seeing it. > > For example, the value of a RadioButton, that may change if another > RadioButton is set. > > > > > 2) This is messy. If a control is a custom control then it appears > > that this line tries to get the property value from the object whose > > class name is the _DrawWith constant defined in the custom control > > not the actual control class? > > The IDE can only display controls that comes from components it uses. > For controls of other components, it relies on the _DrawWith property > that tells him which control to use instead. Of course, that control > must be in one the components used by the IDE. > > > > > 3) I dont understand how the $cValue array is initialised nor indeed > > what its' intent is. Could you enlighten me? > > It's the collection that caches the value of the control property. > > It's not necessarily the real value, but the value you see in the > property editor. For example, the Background property of a control is an > integer, but a String for the IDE. > > > > > Why all this? > > > > I am trying to modify the IDE so that the property editor can use > > special popup editor forms for some extra-special property types for > > custom controls. In short, the goal is to have the property editor > > form inside the custom control component rather than in the IDE. A > > "visible" example is the AngleBox class control "txtAngle" in the > > current IDE. I believe this is only used(?) for the report controls. > > Because we have a bunch of custom controls that have some > > extra-special properties, I have to continually maintain the IDE code > > updates because of svn differences and conflicts. > > > > So, I have so far managed to make a minimal set of mods that allows > > the (local) IDE to recognize custom properties (i.e. the > > extra-special ones) and use a pop-up editor that is contained within > > the custom control component. The pic attached is an example to > > explain it better .. (1) is a custom control, in that control I have > > a property > > > > (2) "Options" that has a custom editor. When I click on the "..." > > button the popup editor shown appears. > > > > and when the Save button is clicked the property "value" is saved > > where I want it. All well and groovy. > > > > In summary, I think this would be a good IDE enhancement. i.e. moving > > the editor for custom control extra-special properties from inside > > the IDE to within the custom control component itself. So... > > > > tia bruce > > > > The IDE can't use code located in other components, because he will have > to load them, which is not always possible. So the code that "manages" > special properties can't be inside the components. > > So I put them directly in the IDE. It's not nice, but it's not a > problem, because the IDE is always released with the entire Gambas > development stack, so you can ensure that everything is synced. > > Now the IDE source code should be better organized if you and other want > to develop custom dialogs for special properties. > > If you want to have custom dialogs associated with custom components, > I'm afraid it's not possible at the moment. > > What is needed is: > - A way to have a gambas library side by side with a component, that > would include the custom dialogs. > - A way for the IDE to load these libraries automatically at runtime. > - A way for the IDE to unload a library. This is not technically > possible, the interpreter being unable to do that. > > And you forgot to attach your image. > > Regards, > > -- > Benoît Minisini > > ------------------------------------------------------------------------------ > _______________________________________________ > Gambas-user mailing list > Gambas-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user Thanks Benoît and Tobi for the responses. They and a bit more experimentation shows me that yes this is a bit more complex than I initially thought. It seems that the design I had in mind will only work for properties in custom controls with a certain set of characteristics and further only if some out-of-hand rules apply. My local mods work here for the half dozen or so of our custom controls that need special editors. Nevertheless I have now comparmentalized all we need here in a single method in FProperty, which makes the conflicts a lot easier to manage. C'est la vie. Some notes of explanation: 1) Obviously the external editor cannot fully "manage" the property within the IDE, for example it cannot provide a means to write out to the .form file. In the cases here we actually use project data files completely separate to the source files and they are static data so there is no problem including them in the project and thus the executable. 2) Yes the IDE has to load the external component containing the custom control class. This is problematic in that the IDE knows the name of the custom control class but not the name of the component it resides in. At the moment I use a very sub-optimal approach that just loads each component "ticked" for the project until it finds the class it is looking for. Obviously this is fraught with the danger that more than one component may contain that class name. But so far I have not had such a mishap. 3) There is a problem in that if a custom control has more than one special property then more than one editor is needed. The IDE then would need to interrogate the component somehow to find the right popup form to use. I have temporarily solved this by using a constant with a specially structured name ("__Edit_<propertyname>"). Sub-optimal but it seems to work OK here. 4) The picture was forgotten in the original post. I did post a reply with it in but it did not get through apparently. Is 154KB too big? regards bruce -- B Bruen <adamn...@gnail.com (sort of)> ------------------------------------------------------------------------------ Full-scale, agent-less Infrastructure Monitoring from a single dashboard Integrate with 40+ ManageEngine ITSM Solutions for complete visibility Physical-Virtual-Cloud Infrastructure monitoring from one console Real user monitoring with APM Insights and performance trend reports Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140 _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
