Updated FormExDestop and ControlsExDesktop libraries

Byak@

Active Member
Licensed User
checkboxex1.new(formex.controlref,0,0,100,100)
doorex.new1(b4pobject(2))
door.new1(false)
doorex.fromstring("main.checkboxex1")
door.value=doorex.value
door.setproperty("Tag","test")

door.fromcontrol(checkboxex1.controlref)
door.setproperty("Tag","test")
red have error (sorry,error in my OS on Russian) but green work right!
 

agraham

Expert
Licensed User
B4X:
doorex.fromstring("main.checkboxex1")
door.value=doorex.value
[COLOR="Red"]door.Value = Obj1.GetProperty("ControlRef")[/COLOR]
door.setproperty("Tag","test")
DoorEx.FromString gets a reference to the Basic4ppc library object, not the underlying CheckBox control. The reason for providing FromString is explained in the third paragraph of the help Overview topic - but it is a bit heavy going :(
 

Byak@

Active Member
Licensed User
Thanks)
it work.
but if i'm do it with native basic's controls (panel,Image and etc.) i have error :-D
without door.Value = door.GetProperty("ControlRef")
all work. but don't work with checkboxEX :-D i'm crazy?
 

agraham

Expert
Licensed User
i'm crazy?
Maybe :) but not about this which is expected behaviour.

The native controls are real controls, they inherit from the actual .NET controls and a reference to them gives you direct access to the properties and methods - they need no ControlRef property.

Library objects are wrappers for controls, they do not inherit from the underlying .NET controls, they carry a reference to the actual control internally and access the control properties via that reference. This reference to the actual control is usually made available through a Value or ControlRef property. Making a library control a wrapper for a control rather than the control itself allows only a sub-set of the available methods and properties to be made visible in Basic4ppc. The compiler and IDE enforce this subsetting for the native controls.
 

Byak@

Active Member
Licensed User
:) Thanks for info)
 

Cableguy

Expert
Licensed User
Hi Andrew,

Im having a bit of trouble trying to open this dll help file, the table of contents does show, but the acctual help text does not, as in the images below...
Another thing, is anyway to set the toolstip button style to other than flat?

 
Last edited:

Cableguy

Expert
Licensed User
I have tried those,but I had the read only prop on, so the unblock was not being aplied, all working now...
About the button issue...any thoughts????
Another request...is it possible to change the font for the toolstrip elements? Can it be added?
 
Last edited:

agraham

Expert
Licensed User
About the button issue...any thoughts????
I can't see any way to alter a ToolStripButtons' style.

is it possible to change the font for the toolstrip elements?
Try setting the Font property with the Door library. You can get a Font from FontDialog in the latest RichTextDesktop, from NormalFont in ImageLibEx or from Font in GdiPlusDesktop.

obj1.Value = tsitem.ControlRef
obj1.SetProperty2("Font", NormalFont.Value)
 

Cableguy

Expert
Licensed User
I wonder if anyone else has ever encoutered or noticed this behaviour....
I setted a FormExDesktop created Form size to be the screen width and height...and I was expecting it to be sized to the screen area and to be taskbar awarem meaning, to be sized to the visible screen when displayed...But it does not...
I tryed with the ClientAreaWidth and ClientAreaHeight but they do nothing, or at least does seem that way...
In other words...How can I resize my form to be the available screen size (height) and be Taskbar aware?
 

agraham

Expert
Licensed User
I tryed with the ClientAreaWidth and ClientAreaHeight
They are read-only properties at the moment. If there is another version issued I will make them writeable.
How can I resize my form to be the available screen size (height) and be Taskbar aware?
As far as I know you can't. If the Taskbar is shown then maximising a FormEx (or any other application) takes it into account automatically. I have my Taskbar set to AutoHide anyway to maximise the screen area - a habit from the days of lower resolution screens!
 

Cableguy

Expert
Licensed User
They are read-only properties at the moment.
I am only reading its value, to no effect!
As far as I know you can't. If the Taskbar is shown then maximising a FormEx (or any other application) takes it into account automatically. I have my Taskbar set to AutoHide anyway to maximise the screen area - a habit from the days of lower resolution screens!
That is my problem, I set windowSate to maximized (value 2), and the form it self is sized to the hole screen as if the taskbar was not visible so the botton 100 pixel or so in height are hidden by the taskbar!!!
I will post some scrrenshot later today, hopefully.
 

agraham

Expert
Licensed User
I am only reading its value, to no effect!
To what no effect? They return the correct values for me.

I set windowSate to maximized (value 2), and the form itself is sized to the hole screen as if the taskbar was not visible so the botton 100 pixel or so in height are hidden by the taskbar
I've just tested this and it works as I expect, at least on Vista. With the Taskbar Autothidden the form maximises to fill the screen and if I specify a form size larger than the screen it initially displays with Height and Width adjusted to fit the full screen. With the Taskbar permanently visible it maximises the form to fill the screen area above the Taskbar and if I specify a form size larger than the screen it initially displays with Height and Width adjusted to fill the screen area above the Taskbar.

Whatever it is doing is the default behaviour for a Windows Form. A FormEx does nothing to alter this.
 

Cableguy

Expert
Licensed User
To what no effect? They return the correct values for me.
I'm not disputting that, I'm just saying that to me they don't...
I've just tested this and it works as I expect, at least on Vista. With the Taskbar Autothidden the form maximises to fill the screen and if I specify a form size larger than the screen it initially displays with Height and Width adjusted to fit the full screen. With the Taskbar permanently visible it maximises the form to fill the screen area above the Taskbar and if I specify a form size larger than the screen it initially displays with Height and Width adjusted to fill the screen area above the Taskbar.

Whatever it is doing is the default behaviour for a Windows Form. A FormEx does nothing to alter this.
I'm working with a Toshiba NB100 with a screen size of 1024 by 600 and a 96 dpi resolution...
Here's the screenshots I promissed:


Test 1 is with no code lines commented out...
As you can see, there's a few pixels gap between the for and the taskbar as well as it is not stretched to the right...


Test2 has a few lines commented out; .maximumheight .maximumwidth .minimumheight .minimumwidth, wich all have the same value in order to prevent the form from being resized by the user.
Here the form takes ALL the screen area, hidding part of it behind the taskbar.


Test3 is the closest to waht I want to achieve, the problem is, all around the form is a small gap of about 5 peixels to every side of the form, that allow the user to un-willingly take action on a form or aplication that is sitting behind this form.
In this case, the WindowState line is commented out.

What I want to achieve is a maximized form that cannot be resized by the user, only minimized..
Sorry for the image size, but this way you don't need to go to imageshack to view the "hole picture".
 

Attachments

Last edited:

agraham

Expert
Licensed User
I'm just saying that to me they don't...
They don't what? You haven't told me what they are returning for you, if anything, and what is wrong with it :confused:

I am away for a few days visiting family around the country however by coincidence I do happen have all the B4ppc stuff on my laptop. :)

In your demo you can't really tell where the bottom of the form is when maximised so I put a Statusbar from ControlsExDesktop on it. My laptop runs XP and just like on Vista on my desktop it all works as I expect. However I don't understand what these two lines are meant to do.
B4X:
   MainForm.MaximumHeight = MainForm.ClientAreaHeight
   MainForm.MaximumWidth = MainForm.ClientAreaWidth
You appear to be resticting the total size of a Form, including border sizes which can vary from system to system) to the area on which controls are drawn which is inveivtably smaller than the current size of the form!

That display size is non-standard and I wonder if there is possibly a display driver problem here. In any case I don't think that there is anything you can do to alter the behaviour. With a FormEx you get the default behaviour of any normal Windows Form for your system.
 

Cableguy

Expert
Licensed User
They don't what? You haven't told me what they are returning for you, if anything, and what is wrong with it :confused:
Sorry Andrew, I feel to have been wasting your time, and I know how much you deslike that...

I am away for a few days visiting family around the country however by coincidence I do happen have all the B4ppc stuff on my laptop. :)
Again I am sorry to be such a pain in the royal..
In your demo you can't really tell where the bottom of the form is when maximised so I put a Statusbar from ControlsExDesktop on it. My laptop runs XP and just like on Vista on my desktop it all works as I expect. However I don't understand what these two lines are meant to do.
B4X:
   MainForm.MaximumHeight = MainForm.ClientAreaHeight
   MainForm.MaximumWidth = MainForm.ClientAreaWidth
You appear to be resticting the total size of a Form, including border sizes which can vary from system to system) to the area on which controls are drawn which is inveivtably smaller than the current size of the form!
Just part of my attempts to work things out...
That display size is non-standard and I wonder if there is possibly a display driver problem here. In any case I don't think that there is anything you can do to alter the behaviour. With a FormEx you get the default behaviour of any normal Windows Form for your system.
I know my screen size is not "Normal", but low-cost laptops, aka net-pc, are becoming a great selling success, so eventually MS, will add theese as standart too..

Now I have another issue, that I can resolve myself for my own use, tweaking the cs file and recompiling the dll, or by using the door dll... but it is just a code line addition to the cs...But this has been a place that I've been and did not like...Respect Andrew, always.
I'm talking about the fact that root menu item in the formex created menus, using .MenuItemStart, do not have a click event, only the sub-menus, created using .MenuItemAdd, have the click menu...
 

agraham

Expert
Licensed User
I am afraid there seems to be a communication problem as I still don't understand what your issues are/were with the Client Area properties and Form maximising. If you post an app that displays the problem on the system in question together with a description of exactly what the problem is and how to reproduce it I'll look at it again.

The reason for not adding the Click event to the root menu items was that I assumed that they would always have at least one sub-menu. I'll add it to the list for the next release. Have you looked at my MainMenu library? It works a little differently to the simplified menu facility in FormEx but is more powerful.
 

agraham

Expert
Licensed User
By request of Zenerdiode ControlsExDesktop version is 1.7 now posted. NotifyIcon now has two new constructors, one takes an Icon type as a parameter and the other takes only a Form requiring the icon to be separately assigned. A new property, FormIcon, returns the icon assocxiated with the Form used to initialise the NotifyIcon.
 

agraham

Expert
Licensed User
As version 2 of my Threading library will operate in the IDE as well as when optimised compiled FormExDesktop needs to be changed to support cross-thread events in the IDE so that threaded FormEx based desktop applications can be tested in the IDE.

The number of events that are raised in libraries from code running on other threads are slowly increasing and will probably continue to do so (is an async version of the Network library coming Erel?). These events are normally safely handled by the main Form of a Basic4ppc application. However when a FormEx is used as the main form events raised on other threads are ignored (in an optimised compiled application) or cause the calling thread to hang (in the IDE). A FormEx already provides a way of handling these events for optimised compiled code and this mechanism has been enhanced in version 1.7 to work in the IDE as well.

Additionally there are new EnableVisualStyles and ARGBFromDecOrHex methods. ClientAreaWidth and ClientAreHeight properties are now writable, The root menu item supports a Click event and for cross-thread events the normal Basic4ppc Sender keyword now works.

The Display object has been enhanced to support multiple displays. You can now find out how additional displays are laid out relative to the primary display in order to programmatically locate forms on them if you wish.
 
Top