Hope some1 can help.
I copied this grid from another WP and seems like its not working. No clue why. Checked all I can but it doesnt work. In the other WP it works properly with another grids.
Any ideas?
Check the columns in the new grid. Does it have the same attributes than the source grid?
If you copied them from a different KB, it is highly possible that the attributes does not keep the same...
The specifier tries to find to which table the attributes belong. Don't think 'it should work because I copied it from a working wkp' , instead think 'some attribute is messing the specification' and take one by one out until it works, check if the obtained table is the desired one or another one. If it is the desired one, then the last attribute you withdrew is the one messing up the specification process. If it is another table than the desired one, try to withdraw from the grid the remaining attributes and put the ones you withdrew before back into the grid, and repeat the process. At some point you will understand which one is messing up. Also keep in mind that there might be other places with attributes, such as in the 'Load Event', they also influence the process.
It means that Genexus can not resolve the base table, you may be using (or referencing) attributes of different transactions and genexus can not resolve the relationship between them.
Related
I filtered my report based on a certain expression. Those that do not meet the criteria that I put in my IFF expression are then filtered and those that do meet it, are shown in my report. My report is multiple pages, so when the filtering happens, some records are left alone on a page, and are not moved up. This leaves a lot of whitespace, and I would like to get rid of that.
On page 1, there will be 2 images/records, with space for one more
On page 2, there will be only 1 image/record that would fit on page one, but doesn't move up
on page 3, there will be only 1 image/record that would fit on page 2 but stays on page 1 etc...
my Keeptogether value is set to true, however this does not help. I have been trying to find something that will keep these records together when filter happens, so that the number of pages is minimal.
If someone could help, I'd really appreciate it.
Regards
Jay
Are you "filtering" via the Visibility in Properties? Because such way will just hide, rather than rule out, the records/images you don't want. If that's the case, try filtering via the Filter in the Properties of the tablix (or Groups, if it applys to your case). But I think the best way is to do the filter job in you data set query, because that will provide you best performance.
So i resolved my problem by adding my IFF expression that I orginially had in the visibility option to the filter by expression option. Everything now moves up and the extra white space that was there before is gone.
Thank you for your help!! :)
I need to find which link among turtle links is the oldest or newest , now I am using a property called , link-order which stores this value for each link and I find it using min-of my-out-links [link-order]
Is there any better way to do this? Without the need to have link-order attribute for all the links?
The only alternative I can think of would be to have a global list of all links, and whenever a link is created, stick it on the end (and remove any nobody entries that have accumulated because of links dying). Then the oldest link is always the first item in the list.
Your original idea seems fine to me too though — neither approach seems obviously superior to the other. I'd probably pick your idea just because it seems a little simpler and less error-prone to code.
I am creating an application with a lot of links. Because the links are contained in cells in a table, the urls that are generated by Wicket tend to get long, making the page slower to load.
For example:
2011-06-09 00:00:00.0
I try to figure out where to start exploring the encoding / decoding of URLs, but it is rather complex material. My first approach was to just use 'short' names for components (like "t", "f" etc). I can imagine there is a better approach.
I can image it would be possible just to 'number' the links; as the page still exists, so I would end up with something like this:
2011-06-09 00:00:00.0
Are there solutions for my problem already out there, or can anyone point me to the right direction?
If a Javascript solution is acceptable, you can use a single event listener on the whole table instead of many links in the table.
See this example for an inspiration:
https://github.com/svenmeier/apachecon-wicket/tree/master/src/main/java/eu/apachecon/base/ui/performance
Notice how the Ajax behavior transports dynamic extra parameters to the server. It looks for rows only though. if you need to distinguish between table cells being clicked, you'll have to expand on the idea.
The solution suggested by Sven is the better solution.
Here is a solution which you may call fundamental: register your own root IRequestMapper that will compress/uncompress the generated urls by the real mappers. See CryptoMapper and HttpsMapper for example of custom root mapper.
I am unable to change the order of modules in Joomla1.6. I tried by clicking the order option . But there are many modules with the same order number and it does not move up or down even after using the arrow keys.
Any thoughts?
Reorder them yourself. Type in 1,2,3,4, etc. according to the manner you want them to be in, then click the 'save' icon next to the order header.
Then refresh your page to ensure they've reorganized appropriately.
When ordering anything in Joomla, make sure the list you are looking at it ordered by the ordering column first. Most times you can not change ordering at all, unless your list is sorted by ordering first.
I know this is a very old question, and Joomla is currently 3.4.8, soon to release 3.5, and the above instructions do not apply any longer, but I thought I should add a small detail here.
In case you are working with a complex template that has many pre-installed modules at various module positions, you may come up with this:Module ordering may not work properly if you are filtering the results in the module manager using a search keyword.
Make sure that you clear search, navigate to the position you need re-arranged (ideally, use the filters on the left column to only show that specific position) and then re-arrange. It should work.
Took me a while to realize.
Currently Magento has a problem with the way it handles mass actions. It returns a bit of JS that contains EVERY db id for the current collection and filter, regardless of pagination. This is to support the 'Select All' vs. 'Select All Visible' option in the grid header. This isn't such a problem when you have a smaller number of records, but if you have 850k records (orders in this case) it becomes a serious problem.
My question is, does anyone have an elegant solution to this problem?
I can think of several solutions, each with its own drawbacks, but I'm hoping someone has solved this in a simple manner that works as an add-on module. Paid or Open-Source solutions are both welcome suggestions.
Clarification:
I'm looking for an elegant/drop-in solution to the problem of 850k+ records using the grid widget in Magento. The stock Magento code makes the bone headed decision to return the id for every record that is matched by the current filter, even if they are not being displayed. This is not about offline processing of records, it's about using the grid widget for daily admin tasks.
One possible solution would be to store the results of the filtered search in a temp table and return a reference to the search result. Then you could change it from using the actual ids on a 'Select All' to using a specific callback for the action using the reference. This would preserve the current behavior.
So, to ask again, does anyone have a good solution to this already created?
I'm running heavy operations from within a shell script. I have a generic iterator (in my case products, but can be done with everything else), and I only implement a class that does the action on the product. My product_iterator shell script takes care of looping over the products, while processing only x products at once (to avoid memory leaks).
Well, the least invasive solution to the problem is to turn off the 'Select All' option for grids with large numbers of records. This is easily accomplished by extending the grid class and adding the following code:
protected function _prepareMassaction()
{
$this->getMassactionBlock()->setUseSelectAll(false);
return parent::_prepareMassaction();
}
I think that fbmc has the right general approach. Clearly, even if you did find a way to send back all 850k records, the framework would have a heart attack attempting to deal with them all. Run the logic in a shell script if this is what you need. For some jobs, you may even need to run them in batches or move down to actual SQL logic.
Unfortunately, some parts of the framework were not made to handle this kind of scale. You've found one of them.
Hope that helps!
Thanks,
Joe
Recently i have written an article about 'Adding new mass action to admin grid in Magento',
Hopefully you will like it:
http://www.blog.magepsycho.com/adding-new-mass-action-to-admin-grid-in-magento/
It describes the two way for adding Mass Action
1> Extending Grid Layouts _prepareMassaction() method
2> Using event: core_block_abstract_prepare_layout_before (more upgrade proof way)
Thanks
Regards