I am working on an application build on Dojo 1.4 and currently used on IE8.
When tried to run IE10 Compatibility view, I observer some X (to clear the data) are being show in the fields like dijit.form.Select. While in IE8 it doesn't display them
Please guide to remove them or what basically is happening
Thanks in Advance
If this is the same problem I just fixed then the question isn't referring to the IE10 "clear field" X. It's referring to a very large text "X" character that is displayed in the Select widget in addition to the options that are supposed to be there, making the widget twice as tall as it should be.
In my case it was because I was mixing the CSS stylesheet from one Dojo version with the API's from another. Check to make sure that your stylesheet and dojo.js versions match. For example, in my case the stylesheet was:
...href="//ajax.googleapis.com/ajax/libs/dojo/1.7.5/dijit/themes/claro/claro.css" media="screen">
while the script being included was
... src="//ajax.googleapis.com/ajax/libs/dojo/1.10.1/dojo/dojo.js"></script>
I blame the fact that I was modifying Dijit sample code without knowing what the heck I was doing...
Related
In order to refresh a part of the grid, i.e., when font or alignment changes, I was using the following approach:
wxRect rect1=CellToRect(TopLeft);
wxRect rect2=CellToRect(BottomRight);
wxRect r(rect1.GetTopLeft(), rect2.GetBottomRight());
RefreshRect(r);
This was refreshing only a part of the intended block and was not working correctly.
From the suggestions of intellisense I came across RefreshBlock function and it works correctly. I searched the docs and have not found any information on it. I wonder if it is not recommended to use RefreshBlock for some reason? What does RefreshBlock do, does it refresh a block (as the name suggests) or is it equivalent to Refresh?
I am using wxWidgets 3.2 on Win10.
Thanks in advance.
The function RefreshBlock() is indeed the best way to do what you want and it was only undocumented by mistake, i.e. we simply forgot to do it. I've added documentation for it only now, so it will only get included in 3.2.1, but you can still use it in your code, the function itself is available since 3.1.3.
It seems from the source code that, depending on the location of its parameters, RefreshBlock refreshes any of the following:
corner grid
frozen cols grid
frozen rows grid
main grid
Since the area I wanted to refresh was on the main grid the following approach works (the idea is similar to RefreshBlock's approach):
auto GridWnd = CellToGridWindow(TL);
wxRect rect = BlockToDeviceRect(TL, BR, GridWnd);
GetGridWindow()->RefreshRect(rect);
Now everything is refreshed correctly.
Notes:
If only RefreshRect(rect) is called, things will NOT work as expected.
Little experiment showed that BlockToDeviceRect(TL, BR) also works, therefore eliminating the need for auto GridWnd = CellToGridWindow(TL);
Using the benchmark statistics I obtain the memory use tag in the html page but it does not give me any related graph, the part of my benchmark xml file is:
<problemBenchmarks>
<xStreamAnnotatedClass>org.optaplanner.examples.myproblem.domain.MySchedule</xStreamAnnotatedClass>
<inputSolutionFile>data/myproblem/unsolved/[26]Day(16.01.15-10.02.15).xml</inputSolutionFile>
<inputSolutionFile>data/myproblem/unsolved/[25]Day(16.01.15-9.02.15).xml</inputSolutionFile>
<inputSolutionFile>data/myproblem/unsolved/[20]Day(16.01.15-4.02.15).xml</inputSolutionFile>
<inputSolutionFile>data/myproblem/unsolved/[15]Day(16-30.01.15).xml</inputSolutionFile>
<inputSolutionFile>data/myproblem/unsolved/[10]Day(16-25.01.15).xml</inputSolutionFile>
<inputSolutionFile>data/myproblem/unsolved/[5]Day(16-20.01.15).xml</inputSolutionFile>
<inputSolutionFile>data/myproblem/unsolved/[2]Day(16,17.01.15).xml</inputSolutionFile>
<inputSolutionFile>data/myproblem/unsolved/[1]Day(16.01.15).xml</inputSolutionFile>
<problemStatisticType>BEST_SCORE</problemStatisticType>
<problemStatisticType>STEP_SCORE</problemStatisticType>
<problemStatisticType>CALCULATE_COUNT_PER_SECOND</problemStatisticType>
<problemStatisticType>BEST_SOLUTION_MUTATION</problemStatisticType>
<problemStatisticType>MOVE_COUNT_PER_STEP</problemStatisticType>
<problemStatisticType>MEMORY_USE</problemStatisticType>
<singleStatisticType>CONSTRAINT_MATCH_TOTAL_BEST_SCORE</singleStatisticType>
<singleStatisticType>CONSTRAINT_MATCH_TOTAL_STEP_SCORE</singleStatisticType>
<singleStatisticType>PICKED_MOVE_TYPE_BEST_SCORE_DIFF</singleStatisticType>
<singleStatisticType>PICKED_MOVE_TYPE_STEP_SCORE_DIFF</singleStatisticType>
</problemBenchmarks>
Where is my wrong action?
A screen shot for the Memory_Use:
A Screen shot for the Best_Score, note that when I clicked the memory use tab no change from using the best score tab:
The behaviour looks similar as described in this jira: a bug in the generated anchor id's. But I can't reproduce it in 6.4.0.SNAPSHOT, so I suspect it was fixed a long time ago (that jira can't have fixed it).
You should upgrade from 6.2 to at least 6.3.
I am helping a co-worker with a issue in a production datatbase. The database makes use of a visual indicator to show the user during long partial refreshes. We are in the process of upgrading the application to Notes 9.0.1.
The method that is used is described in detail in this blog post by Eric Tomenga: https://www.socialbizug.org/blogs/tomenga/entry/dojo_loading_image_indicator_while_partial_refresh_loads_data?lang=en_us (blog that Eric's references appears to be offline)
The code is not altered from what is shown in the post. Works in 8.5.3 completely, but in 9.0.1, the "Please Wait" works but the spining image is absent.
My suspicion is that newer dojo version that Notes 9 uses changes something that breaks this. Downgrading dojo versions is not an option. Hoping for a workaround.
<xp:this.onStart><![CDATA[XSP.startAjaxLoading()]]></xp:this.onStart>
<xp:this.onComplete><![CDATA[XSP.endAjaxLoading()]]></xp:this.onComplete>
<xp:this.onError><![CDATA[XSP.endAjaxLoading()]]></xp:this.onError>
This is added to the element you want to use it with (button in this case). The following dojo modules are added to XPage resources: extlib.dijit.ExtLib + extlib.dijit.Loading
I'm pretty sure you'll need to add the relevant Dojo module as well. You can see a working example of the code on the Admin page of the XPages Extension Library demo database. I can't remember off-hand which dojo module it is, so please post here if that solves it.
I want use Gridster for my web site, but i need to add lot of widgets with "add_widget" command. I do a test and i think there is a problem with "add_widget" function : grid is more and more slow and there are memory leak.
You can see that in this video : grister problem video
However, as you can see on the video, if i add widget at beginning (not with add_widget function) there is no problem. Can you help me ? Something wrong with my code ?
Thanks in advance !
In my own experience, the main culprit was using the autogenerate_stylesheet setting. The problem is that it regenerates the css on every call to add_widget(), and this just absolutely kills browsers. Additionally, gridster has/had a bug where stylesheets get duplicated, filling the <head> with tons of duplicate style rules, making it tough on the browser(this bug was supposedly fixed, but my experience was that the fix only worked in specific scenarios, definitely not in mine).
When I used gridster, my widgets were always the same size. So, in my case, I was able to generate the stylesheet once, never needing to regenerate it.
I don't think its part of the public api, but you can just call generate_stylesheet() method once manually.
var gridster = $(".gridster ul").gridster({
autogenerate_stylesheet: false,
widget_base_dimensions: [140, 140],
//other options...
}).data('gridster');
gridster.generate_stylesheet({rows: 30; cols: 8});
//freely call gridster.add_widget(...); as many times as you like
Since you're only going to generate the stylesheet once, you need to make sure gridster will generate style rules for enough rows and columns to accommodate all your widgets, otherwise once you exceed the range, you'll experience broken layouts. Just supply an upper bound on rows and cols when calling generate_stylesheet(opts). If you don't, it seems like it defaults to whatever value your gridster instance is using for max_rows and max_cols.
The nice thing is by manually generating the stylesheet, is that you completely avoid the duplicate style bug too.
The exponential slowdown will be gone. Happy gridstering.
I know I'm a bit late on this but I had the same problem and none of the above solutions worked.
However, I found that I was generating the size and coordinates of the widgets as a string rather than an integer on the back-end.
By making sure they were integers I managed to speed things up loads.
The best way to fix it, is not to disable the autogenerated stylesheet, but to edit the fn.generate_stylesheet function in jquery.gridster.js
At the end of the function, just before these lines:
return this.add_style_tag(styles);
};
add this line:
this.remove_style_tags();
The final result would look like this:
this.remove_style_tags();
return this.add_style_tag(styles);
};
With this, each time a stylesheet is generated, the previous one is removed, so there no duplication problem!
I was started to work on my first sample of the dijit.Tree control.
When it didn't work, I added a couple of dijit.form.Textbox'es to the screen, and they didn't work either, even though I have them working fine on a similar form.
Interesting enough, when I killed FireFox and restarted it, I was got a clear message in FireBug console on what was wrong with my tree control, and got it fixed.
But now I'm rather puzzled while the simple dijits like NumberTextBox that I added are not working.
My Samples:
1) http://3wcloud-com-provisioning-qa.appspot.com/testDijitDate - this works great
(except the initial date value not showing - I have a separate question open on that)
2) http://3wcloud-com-provisioning-qa.appspot.com/testDijitTree
I've done several "diff"s on the two files, and I kind find the difference that would cause one to work and one not to work.
Thanks,
Neal
You should put your dojo.require statements immediately in a script block, not wrapped in the onload callback. Also, your input tags should be HTML style without the XHTML style slash (you didn't declare XHTML in your document) though I doubt that's the problem. See if either of those things help.