Where is the multi selection button in Gui Builder 4.32? In previous version tutorials it appears, but not the encounter in this version. What am I not seeing?
That feature was removed a while back and wasn't added back as far as I recall. We had some bugs with that feature and most people didn't even notice when it was removed.
You can file an RFE in the issue tracker if you want us to look into adding it back.
Related
Now that things are sort of getting stable, I am still doing the codename one todo app demo and got to the point where I added underlines under the label/checkbox. My git repo is
https://github.com/deanhiller/codenameOneExamples
****EDIT
I just published my build and ran on android phone and the basic todo app is not working either. I am not sure what's wrong, and if I can't fix this it may be time to jump ship and create two apps(one swift and one android studio...bleck ). I really like this concept and at 70/month, codeone was not a bad deal for what we need.
****END EDIT
If I click + 3 times though, the screen looks like this (settled on using intellij 2019.1.4 with codename 6.5.1 on MacOS Catalina 10.15.4). This is not what the demo should look like though.
and thanks at the amazing support Shai.
It seems you only defined the styles for the unselected theme. This means that when an entry is selected or pressed it's unstyled. You can see this by opening the theme in my repo and comparing it to your theme.
Since I wrote that book we've slowly moved to styling with CSS which isn't very different from the content of the book (slightly different syntax). That makes things like that easier since CSS implicitly defines all the 4 styles in the same way and changes things for a specific style explicitly. This is a bit more convenient. It's also easier to treat styling as code even though I'm not a fan of CSS.
The nice thing if you can "live edit" CSS which means changes instantly show in the simulator without interaction.
We tried more time to find badges with android using codename one, but I found some comments in stackoverflow is only working on IOS and not working on android, if true so when will it become available on android?.
Thanks in advance
When we created the badge code Android didn't support that UI paradigm. Arguably it still doesn't but some vendors include that functionality with a special API.
Currently the main thing holding this back is that no one asked for it or implemented it. First of all I suggest filing an RFE which will give you a way to track the schedule for adding this. You can add an RFE on http://github.com/codenameone/CodenameOne/issues/
You can also just implement this yourself and submit a pull request as explained in this post: https://www.codenameone.com/blog/how-to-use-the-codename-one-sources.html
This should be relatively easy although you will need to be careful with using the right API level options and might need to use reflection to avoid SDK dependencies which we don't want.
Other than that it's just a matter of interest if we need to implement it. If you have an enterprise account then make sure to let us know through the account of your interest in this feature. We also take pro account requests more seriously when assigning a feature.
About obfuscation, what is the meaning of "rim.obfuscation"? I didn't find on Internet what is the "rimc compiler".
It's a legacy build hint related to RIM (Blackberry) support. Since that support is deprecated we removed some of the docs for it.
Our old plugin UI in the preferences still has UI for this and adds those hints automatically. We hope to remove that UI on NetBeans/Eclipse so only Codename One Settings remains but removing code is sometimes just as hard as adding it.
As I write this question, 2 days after the beta of .NET 4.5 was released, the What's New in WPF 4.5 Version 4.5 Beta page on MSDN still lists "Integrating WPF with win32 Graphical User Interfaces" as an area in which WPF 4.5 offers improvements. That page talks about the two new properties on HwndHost that support this: IsRedirected and CompositionMode. Also, the top-level what's new in .NET 4.5 beta page mentions this integration as a new feature.
Again, as I write this, there are pages for those two items. You've got IsRedirected here and CompositionMode here. (Update 27th Jan 2014: original pages no longer available, so I've moved these links to point to the Internet Archive copies.)
However, if you go to the docs for HwndHost itself, neither of those properties is present. And they don't appear to be in Visual Studio either.
So it would appear that the rumours are true - it looks like the airspace improvements for interop have been dropped. But just in case anyone from Microsoft is reading this, it would be good if a) we could get positive confirmation and b) the pages mentioned above could be updated to stop getting our hopes up.
Update 27th Jan 2014: I've updated the links for IsRedirected and CompositionMode to point into the Internet Archive, because the original links are now dead. Also note that the What's New pages no longer mention this because those links are now for the final release. You can see the old pages that were current when I originally asked this question at this archived page and here.
There is a rather good blog post from Dwayne Need that describes the extraordinary effort they put in trying to make it work. Nothing subtle, they for example ending up intercepting over 200 GDI functions to get them to play along with the WPF rendering model. The outcome was to be expected:
You can imaging my heartbreak when, after an extensive review, we decided we could not actually ship this feature. Our concern was that we had to hack too deeply into the system, and in ways that were too difficult to explain - let alone maintain. Even though we required that developers explicitly turn on this feature for each HwndHost, we felt the kinds of problems they would encounter would be baffling to them and training our support engineers to handle the escalations would be very difficult. Even towards the end of our development, we were struggling with a long bug tail and performance concerns.
This is exactly the kind of deep system integration that needs to be done by the Win32 platform team, officially sanctioned and supported. With Win8, we are beginning to see some incremental improvements in this space, as noted before in the DirectComposition API. Unfortunately, it is still not possible to build the same kind of rich composited experience we had developed.
Whether the Windows group is going to commit to providing this kind of integration is right now an open question. They certainly put their money on a very different horse and spent a lot of effort on WinRT, a rendering model that's certainly inspired by WPF but doesn't do anything to make it better. If it is going to be tackled at all then count on years to get there.
Do check the rest of the blog post as well. It has excellent, albeit it high-level, advice on addressing existing airspace issues.
A suggestion to "Bring back the HwndHost.IsRedirected and CompositionMode" was posted at the Visual Studio UserVoice.
Microsoft declined it, saying:
at this time, we will not be able to add the feature to WPF and the .NET Framework.
It also looks like the MSDN pages you linked to have been taken down.
I am working on my first DotNetNuke website and there is a requirement for all the custom module functionality I am developing to be available with JavaScript disabled.
However, when I create a module that contains a simple submit button, i.e.<input type="submit" />, DotNetNuke displays a critical error with JavaScript turned off but works as expected with JavaScript turned on.
When I attach to the running process using Visual Studio, the unhandled exception is thrown from admin/Skins/Nav.ascx.vb line 177. The inner exception message is "Invalid JSON primitive: ."
My research online only managed to turn up this forum post (Postbacks are not working when Javascript is disabled in the browser) that appears to be the same problem as mine, but no solution is provided.
Can anyone shed any light on this issue? Is it viable to be attempting to write non-JavaScript functionality in this version of DotNetNuke?
Update: it turns out that another website designed recently with Dot Net Nuke by the company I am working for is having the same problem with non-javascript postbacks when using DNN version 5.1.4 but it does not have the problem (i.e. it can postback without javascript) in DNN version 5.0.1.
So perhaps a hard dependency on javascript has been introduced at some point after version 5.0.1. We are investigating this possibility further and I will keep this question updated as we go. Obviously I still welcome anyone's input on the subject.
Update: i've started a thread on the Dot Net Nuke forums to see if I can get any help there. If any solutions come up I'll post them here. Trying to find official DNN stance on support for javascript disabled functionality
One of the developers in the office found a workaround to get postbacks working with javascript disabled. Unfortunately since he does not have a Stack Overflow account, I will try to translate his solution as best I can for those who are interested. Bottom line is postbacks with Javascript disabled is possible once you make a few changes to the Dot Net Nuke environment.
Step 1 - Change the menu module. In our case we used the Telerik RadMenu.
<dnn:NAV runat="server" id="dnnNAV" ProviderName="DNNMenuNavigationProvider" IndicateChildren="false" ControlOrientation="Horizontal" CSSControl="mainMenu" />
becomes
<dnn:RADMENU runat="server" id="dnnRADMENU" MaxLevel="2" EnablePageIcons="False" PagesToExclude="" ShowPath="True" />
Step 2 - Remove the actions and visibility modules.
<dnn:ACTIONS runat="server" id="dnnACTIONS" ProviderName="DNNMenuNavigationProvider" ExpandDepth="1" PopulateNodesFromClient="True" />
<dnn:VISIBILITY runat="server" id="dnnVISIBILITY" minicon="images/DNN-minus.gif" maxicon="images/DNN-plus.gif" />
Step 3 - Download the DNN source and make two changes in the LibraryUI\Utilities\ClientAPI.vb file.
Line 155:
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
becomes
If Not objButton.Page.IsPostBack Then
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
End If
Line 355:
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
becomes
If Not objPage.IsPostBack Then
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
End If
Step 4 - compile the Dot Net Nuke library.
Note: Also make sure you are not logged in as an admin or host, as the admin/host panel at the top of the page will also break if you attempt to postback with javascript disabled.
Hope this helps someone else. If you feel like I'm missing some important details, let me know and I'll try and fill in what's needed.
DotNetNuke relies heavily on JavaScript and I doubt there is a real easy way around it - at least considering you need to support all functionality. Perhaps you can clarify that?
The the bottom line here is that you're going to need to modify DotNetNuke to meet your needs. It certainly isn't impossible to get it working, but I would venture a guess that it just plain isn't worth it for most people.
If, as you said, you need to retain ALL functionality without using JavaScript, you're going to have a pretty substantial amount of work to do.
I'd suggest, to get started, you download the source package, set up a development environment on your local machine, turn off JavaScript in your browser and start taking notes. This will help to determine the level of effort involved.
I'm guessing you won't get a lot of responses out of this one (as the poster in the forum thread you linked to didn't) as very few people have sat down in front of DotNetNuke with this as a requirement.
Also, keep in mind that any time you're making substantial changes to the DotNetNuke framework, you're interfering with your ability to easily perform upgrades in the future. Just another thing to think about.
I believe that I've seen the leadership in DNN say that they've taken a hard dependency on JavaScript, and have no intention at this time of considering a non-JavaScript compatible scenario.
That being said, being able to do a simple postback shouldn't be too difficult to support. I would look around in the Client API area for the error that you're describing. A lot of the Client API code is in the DotNetNuke.WebUtility assembly, which is a separate download from CodePlex to get the source.