I don't know because you haven't given enough information as to what you are doing or what the error is!
-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Updated FormExDestop and ControlsExDesktop libraries
- Thread starter agraham
- Start date
- Similar Threads Similar Threads
B4X:
doorex.fromstring("main.checkboxex1")
door.value=doorex.value
[COLOR="Red"]door.Value = Obj1.GetProperty("ControlRef")[/COLOR]
door.setproperty("Tag","test")
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.
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?
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:
You can fix the help file problem by:
- Right click on the help file (extension should be .chm)
- Properties
- Choose Unblock file
Another option is to open the file by double clicking on it. You will see a warning about the file. Uncheck the 'always ask for permissions...' at the bottom of the dialog and from now on it will work.
- Right click on the help file (extension should be .chm)
- Properties
- Choose Unblock file
Another option is to open the file by double clicking on it. You will see a warning about the file. Uncheck the 'always ask for permissions...' at the bottom of the dialog and from now on it will work.
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?
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:
I can't see any way to alter a ToolStripButtons' style.
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)
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?
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?
They are read-only properties at the moment. If there is another version issued I will make them writeable.
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!
I am only reading its value, to no effect!
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.
To what no effect? They return the correct values for me.
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 not disputting that, I'm just saying that to me they don't...
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".
Last edited:
They don't what? You haven't told me what they are returning for you, if anything, and what is wrong with it
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.ClientAreaWidthThat 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.
Sorry Andrew, I feel to have been wasting your time, and I know how much you deslike that...They don't what? You haven't told me what they are returning for you, if anything, and what is wrong with it
Again I am sorry to be such a pain in the royal..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.
Just part of my attempts to work things out...
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...
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.
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.
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.
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.
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.