We're currently researching if it is possible to on the fly generate/change the UI of a metro app. So far I have seen only that the reflection options are somewhat limited. But perhaps if we're using HTML/JS we can modify the HTML on the fly? Anybody tried something like this?
Will fire up VS later and give it a go, just thought I'd ask here and see if we could have a disucssion on the topic.
Most Javascript-based apps modify their HTML on the fly as this is a pattern promoted by the Navigator template. So for example even just clicking a link and navigating to another page will replace the content of a 'page' container element instead of reloading the whole page and thus reloading all .js and .css files.
Also the WinJS.UI.ListView will dynamically create and reposition elements in your DOM as you scroll its contents.
Basically you can do anything you'd do in a webapp and re-use patterns like known from AJAX to make your UI adapt dynamically.
Depending on what you want to achieve, you should with increasing complexity keep in mind that your app should be able to suspend and restore its state from scratch at any point.
Related
I am building my first electron desktop app. It creates a formatted document/book from spreadsheet data to either be printed or made into a PDF. I am trying to figure out the best way to prevent performance loss from reflow/repaint when having a large document(lots of divs). I have found that if I have the book in an iframe then I do not suffer reflows/repaints from UI changes and can control when to have it loaded. If I try to create a PDF however I will only get the amount of the iframe that is visible.
Simply, I'm looking for the best solution to prevent reflow in a complex HTML element while still being able to print it to PDF.
I've found a solution to the problem.
As far as I understand, for an electron desktop app, that is not running a server, you cannot directly access myIframe.contentDocument on elements for actions such as append, innerHTML, or offsetHeight etc. The only thing you can do is contentDocument.write(), however once you have used this method, you have access to all of the other regular DOM methods. The best I can understand is that when you use contentDocument.write() it essentially creates a virtual HTML document. This is my workaround at the moment which is working like a charm in giving me control over what elements reflow and what ones do not.
Hope this helps anyone dealing with the same issue.
I wanted to consult with the sages here regarding Qt and skinning, get your opinion and chart a path for my development. My requirements are as follows:
My Qt/C++ application (cross platform with Mac, Windows and Linux versions) needs to have modular skins.
A skin is defined as a set of one or more elements: - Window background texture - Look/feel of UI controls such as edit boxes, drop down, radio buttons, buttons etc. - Look/feel of window "caption", resize grips etc.
Skins will be installed with the application installer, allowing the user to choose which one he/she wants to use. Users should be able to change skins on the fly.
Can I go the QML route? should this be custom and based on simple resources which are built into the application? Any design advice will be appreciated.
Thanks.
If I understood you correctly then stylesheet is the best way forward. You can create stylesheets similar to CSS and then pass them as command line option to your application or load on invocation to style your application at runtime. That way you can create multiple stylesheets each having a different look and feel and allow user to load them at will. Since its CSS it doesn't need any new learning and you can keep all your styling outside your source code.
Here are a list of resources that can get you up and running quickly:
http://blog.qt.io/blog/2007/11/27/theming-qt-for-fun-and-profit/
http://doc.qt.io/qt-5/stylesheet.html
I haven't played with QML yet, but you could also create a custom QStyle implementation that supports your resource format. Note that you'd lose style sheet support if you went this route.
Changing window captions is a little trickier if you want portability.
QML, if I understand correctly, doesn't really skin the widgets, it mainly deals with GUI layout etc etc.
QStyle is used to change the looks. It is a bit low-level though, and requires programming, so if you want to load different user-created skins (from an XML or so) it might be tricky to support extensive skinning. Chaining colors and a few items are easy enough though. (There might be someone else who've done something you could re-use.. not sure.)
For modifying widgets, use QStyle::polish(). You could use that to change the background picture (if it's a top-level window, or of a certain class). There are numerous repaint method to change almost every part of every widget.
Store/load the style using QSettings, by reading and setting the desired Style just after QApplication but before your main window is constructed.
I am working on a Facebook iFrame application, and have a question about styling.
I want the application content to look like the rest of facebook. So the most obvious approach I could think of was to use a stylesheet provided by Facebook for application development that includes such styles. However I cannot seem to find anything about this on developers.facebook.com or any other site for that matter.
I have created some FBML application earlier, and these was able to use Facebook styles directly since the application content was rendrered within the facebook pages. But iframes does not inherit the stylesheet from the parent content (nor should they), so I was wondering how (or possibly if) this can be done.
I have found some posts/blogs that simply tells you to create an application stylesheet that mimics the Facebook look. But I don't think this is a very good idea, as this CSS must be updated every time anything changes on Facebook. It also seems that all facebook wiki pages regarding CSS (which I have used before) has been removed.
The reason I do not want to use FBML Canvas is that Facebook is in the process of deprecating this approach. They recommend new applications to be created using iframes.
http://developers.facebook.com/docs/reference/fbml/
I really hope anyone has any good ideas on this.
There is no official way. For some reason, FB shards their styles to a ridiculous degree. They also change the filename rather than appending a version parameter every time they make a change to prevent downstream caching. Here's an example of todays stylesheets:
http://static.ak.fbcdn.net/rsrc.php/y-/r/40PDtAkbl8D.css
http://b.static.ak.fbcdn.net/rsrc.php/yE/r/u7RMVVYiOcY.css
http://static.ak.fbcdn.net/rsrc.php/yT/r/P-HsvhlyVjJ.css
http://static.ak.fbcdn.net/rsrc.php/yT/r/CFyyRO05F0N.css
http://static.ak.fbcdn.net/rsrc.php/y0/r/k00rCIzSCMA.css
http://b.static.ak.fbcdn.net/rsrc.php/yv/r/BJI6bizfXHL.css
http://b.static.ak.fbcdn.net/rsrc.php/yD/r/rmbhh_xQwEk.css
http://b.static.ak.fbcdn.net/rsrc.php/yn/r/xlsrXFt9-vD.css
http://b.static.ak.fbcdn.net/rsrc.php/yN/r/Uuokrl6Xv3c.css
http://b.static.ak.fbcdn.net/rsrc.php/y0/r/klTGALEjWM8.css
http://b.static.ak.fbcdn.net/rsrc.php/yN/r/mlYhlJwnCdr.css
http://b.static.ak.fbcdn.net/rsrc.php/yT/r/uFI2FW2LitH.css
http://b.static.ak.fbcdn.net/rsrc.php/yh/r/5Bzj1255G1S.css
http://b.static.ak.fbcdn.net/rsrc.php/yp/r/5UteuBI1b8_.css
You can automate this process fairly easily using either PHP or .NET using existing solutions Minify and Combiner respectively.
A simpler method would be to use the Web Developer toolbar for Firefox, go to Facebook and choose the Web Developer toolbar option to "view CSS" which will bunch all the CSS up for you. Copy and paste it into your own local stylesheet and you only have to update when Facebook makes a major change.
So while there is no simple way (that I am aware of), there are methods for you take care of it in a fairly speedy manner.
Walter Rumsby provided a great answer to Where to place JavaScript in an HTML file. He references the work done by the Yahoo Exceptional Performance team and their recommendation to place scripts at the bottom of the page. Which is a hard and fast rule that I've been following for quite sometime now. In the same thread Levi Rosol pointed out "the best place for it [JavaScript] is just before you need it an no sooner." That is the predicament that I now find myself in.
I've added my reference to jQuery at the end of my page but have run into an issue with how to structure a user control that I'd like to add client side functionality to. Specifically, I am having a hard time working out the best way to accommodate dependencies. The user control has a span tag containing a numeric value that I'd like to update based on the number of check boxes the user has checked in the user control. I am using jQuery to find the span tag and update its text property.
Unfortunately, unless my reference to jQuery appears prior to the user control I receive JavaScript errors. This makes sense because the control is referencing functions that have not yet been added. I can think of several solutions to the issue but am looking for a best practice option.
Placing a reference to the jQuery library inside of the user control.
Downside: if the user control was placed into a repeater multiple references to the jQuery library would be made.
Put no JavaScript in the user control and write all code to update the span tag for the user control in the containing page.
Downside: I'd end up with the same code in multiple places creating a potential maintenance nightmare.
Place the jQuery reference in the head section of the page.
Downside: I've violated the recommendation to place scripts at the bottom of the page and have created an unusable user control if the page does not include a reference to jQuery.
Those are the options and downsides I came up with when thinking about solutions to this problem. I am certainly open to suggestions for better solutions and barring none looking for a recommendation of which of the three I should choose.
There's a Google project that aims to solve these pains you may want to look at called Jingo:
http://code.google.com/p/jingo/
Another solution I'd recommend is a loader like YUI Loader Utility.
http://developer.yahoo.com/yui/yuiloader/
It will allow you to manage dependencies etc. and it's not just useful when you're using their UI components. It can be used for anything; just look at the docs around addModule.
If you're using ASP.NET the ScriptManager is another good solution.
Another option would be to dynamically generate the script reference by registering a startup script from your usercontrol that wrote a script reference to the document head.
The javascript function could check for an existing jQuery reference, and if none was found, write the reference out. This would solve the multiple references. A basic example was discussed in this thread.
The simplest solution to this I've found is to use a helper to accumulate Javascript fragments to be included at the page body while rendering other page elements. Then, you can include jQuery first, followed by any deferred literal Javascript fragments.
It does require maintaining some extra state during page generation, which can complicate your rendering pipeline just a bit. However, it allows you to get deferred Javascript inclusion, without requiring complex DOM manipulation after the page is loaded to pick out any existing references to jQuery.
Looking for some direction here as I'm running into some migration problems.
We have a legacy application. The 'infrastructure' is running just fine. Business logic and data access layers written in VB calling SQL Server for the database.
I have a LOT of experience writing Winforms (desktop) application and have had no problems. However, the last time I wrote any ASP.NET stuff was in 1.1 (VS.NET 2003).
Among other things, for ASP.NET 2.0 and up, the Grid layout is gone. It's not just a simple case of dropping controls on a form, aligning them, ordering them and working with the code-behind anymore.
The new web-based application is starting out pretty simple. Just a common header (already made a user control for that) and footer with your typical CRUD functions in the middle.
I tried being 'intuative' in using a master page with content place holders but I couldn't get the placeholders to "grow", to say nothing of not being able to put a text box where I wanted one. Oh, I found the option in VS2008 to allow absolute positioning but it only worked for SOME controls - others I had to manually edit the asp tags.
Then I saw examples using div's and tried to implement them but I ended up with results that had objects writing on top of each other. The online help wasn't helpful to say the least.
Does anyone know of a good book, website or tutorial that can give the basics of what I'm looking for? In practice, I'm looking to make simple pages where some objects may have to push others gurther down the y-axis (as in, several comments being made and that section would push the section listing the 'attachments' down further). I have no trouble when it comes to all the other aspects of this application. It just appears that my webforms skills are about 3-4 years out of date.
This isn't going to be some fancy flash/silverlight application - just simple 'data maintenance' to get rid of some ugly and bug-prone processes involving reading common mailboxes and decoding Word files. The new goal is to have a nice weborm with proper validation.
I guess what I'm looking for is a "Webforms for Winforms programmers" book or site.
Help!
Thanks in advance.
The best advice I've heard on learning to use html/css layout goes something like this:
When building a new page, don't try to get all fancy up front. Start by building a very basic, text-only page. It should look like something from 1996- that brief period where everyone had just discovered the web but had not yet started using the table tag for layout- only no comic sans font. Don't use images at this point, unless the image is genuinely a part of the information being conveyed (as opposed to the window dressing to make it look pretty: you can add those later). There will likely be an h1 at the top of the page, and give each sub heading an appropriate hN, but at this point there shouldn't be any layout information in the page at all. The only place you'll have a table tag is if you genuinely have tabular data to show. If it helps you write this code then you can wrap everything in old-fashioned <center> tags for now- just don't forget to remove them later.
Now let's start tweaking the markup a little. Use things like ul (unordered list) for your list of navigation links and label/legend to identify and group your form areas. The general idea here is to have each element on the page encased in the most appropriate html tag, and to use the full set of available tags- each for it's designated purpose.
At this point you have a page that is ideally suited for a screen reader or search engine. By building this page first, you have made SEO and accessibility compliance easy on yourself. Of course those aren't the only requirements, so we're not done yet.
Now you need to identify the different sections of your page, from both the layout and logical perspectives. The page should largely already be divided logically, but you may find a few places where the normal tags don't cut it. You'll also want to group certain elements for layout reasons. Encase each of these areas with a div tag, and give the tag a class name that refers to the purpose for the tag: the group your are creating. This is just another case of using the a tag (the "division" tag) for it's intended purpose. Also, since elements can have more than one class, you may want to think about also grouping your classes logically. For example, you might want to have a separate class that distinguishes the site template from the rest of the page.
By and large this should not have changed the appearance of the page, but now you have something where it should be very easy to start adding styles. At this point you can now start adding images and layout. The goal here, though, is to change the actual markup as little as possible. If you can manage it only add ids and classes, though you will likely need to add an additional span or div that you had not identified earlier, and sometimes you'll need an extra block level element to force a compatible layout across browsers.
If things are done correctly, the result is a page that not only looks good, but is also easier to work with when testing across browsers, will naturally degrade well when a style or javascript feature isn't supported, and scores well for SEO and accessibility. This also makes it easier to have a developer build a simple page that provides a certain level of functionality, which they can this pass off to a separate designer to make it look good.
You may also want to check out A List Apart. This is a great website with lots of "tricks" for using CSS to layout things on the web along with lots of other web oriented content.
Grid positioning was an abomination for websites. Sure it made for an easy transition from those familiar with the WinForms designer, but it produced horride HTML that is nearly impossible to maintain.
The very best resource I can recommend to you is CSS Mastery. You'll need to learn HTML and CSS, but they're quite easy to get into.
By the sounds of it, you're looking for a crash course in HTML ?
the "Design Canvas" of an ASP.NET aspx Page & ascx Control is just HTML tag markup.
If you've no web design experience, I'd recommend starting somewhere like
W3Schools
When Microsoft gave us ASP.NET, they tried to make programming websites, more like programming rich client applications. However, there are a lot of issues you have to deal with, the major one being statelessness, when developing for the web that don't exist when developing a thick client app (WinForms). So the first step is to not think of the two as similar in anyway.
The drag and drop tools are nice, but what you really need to understand is HTML and client server models. HTML will help you understand how things are getting laid out, and client server models are important to understand how data gets to and from the web to the server. If you have developed in ASP.NET 1.1, then things really haven't changed for 2.0. The concepts are the same, just some of the provided controls have changed.
A lot of people were really unhappy with the grid-based layout from 1.1, because it didn't really work in a number of situations. It still has to ultimately render as html, and html just isn't suited to that kind of layout. For example, things might not be ordered properly or pushed off the screen for mobile browsers (iPhone, etc). There's also things like screen readers for the blind. If you work for the government, that 2nd item is a legal requirement rather than just a nice-to-have, and there are a lot of developers who do work for the government.
So ASP.Net 2.0 tried to generate markup that's at least a little nicer for html. The downside is that you actually have to understand html layout now. But, c'mon: you're building a web site. If you can't handle a little html you're in real trouble.
My advice to build one static page using something other than visual studio. Use <input tags rather than server controls on that page and don't actually implement any logic. Use it to understand how your layout will need to work. Once you have that down, it's really easy to duplicate that for your pages in Visual Studio.
This doesn't really belong as a separate answer, but I wasn't sure you were likely to see another comment to my response above.
The normal behavior of all block-level elements, including divs, is for each new element to appear below the previous element. It sounds like you've set position:absolute; on everything, perhaps while playing with the Grid-based layout option in visual studio. Don't do that- it's hijacked the expected behavior and that's why you see everything piled on top of each other.