We have a company 'letterhead' template with all company info in a left column/sidebar. I'd like to lock that section for editing, but still retain the option to edit and/or mail merge the rest of the document as normal. I've tried the Restrict Editing feature, but that seems like the opposite function of what I need; I'd like to specify a section that is not editable, as opposed to a section that is.
The main problem is that the mailmerge/add-envelope function is disabled when Restrict Editing is on, but also adding a section break to a second page (to change to a single-column format on subsequent pages) isn't allowed either.
I've considered just creating an image of the left sidebar, but that seems hacky. Does anyone have any other suggestions on this one?
Much appreciated
--michael~
I opted for a combo of ideas, and used your [Cindy] last suggestion to bury an image in the first-page header. The table/content control seemed too complicated. Yes, it's a hacky solution, but with the wrapping options to prevent text over the image, it's like a margin without having to set them, so I can get rid of the multi-column and Restrict Editing thing, and subsequent pages are completely normal without extra section break necessary. I appreciate the responses. Thanks!
Related
Hope you can help.
I have attached my workbook. Basically, I have made swapping sheets. The sheets have different filters, and I need the filters to disappear depending on the sheet showing.
I have no problem with the sheet swapping. I been going through the internet for hours, without finding a good solution. I did look into this: New series of videos on swapping and popping on a dashboard(https://vimeo.com/294170859), but did not find it that helpful since it is not very flexible and too difficult to use if you have many filters, that need to change.
I have some kind of an Idea, of putting my filters in each of their container, and then have the container showing depending the sheet but do not how either.
But in the end, the filters needs to appear in the same spots too.
But I really need your help - Simply can't find a good solution!
Thank you!
Without putting your filters in containers and swapping those I can't think of any alternative way to alter which filters appear on your dashboard.
I don't know the exact specifics of your task, however, having perhaps faced similar issues almost always the best solution is to simplify. If possible instead of swapping sheets consider a new dashboard and just "show sheets as tabs". Altering a parameter is a click, just as clicking a dashboard tab - so no difference to the user. Also changing filters may be confusing to a user - they generally get used to seeing things in a certain place.
Of course none of this may apply to your specific situation.
Others have asked this question before, but no one has provided an actual answer to it. I can't get all of the marks/labels to display in my Tableau visualizations.
Selecting "allow labels to overlap" does not fix the problem. That displays several hidden labels for the smallest of the areas, and it places those labels at the top of the bars, ignoring the formatting that sets the labels to the bottom. However, whether or not that option is checked, the empty areas in the screen shot stay empty. And those areas are clearly large enough to display the missing labels without encroaching on any other label.
I'm guessing this is a bug in Tableau because there's no reasonable explanation as to why this is happening, but I'm new to Tableau and unsure how to address this.
While I can offer no explanation, this has been a reported problem for several years. Tableau's own documentation states to check the Allow marks to overlap checkbox, yet that doesn't always work.
I don't know if it's a bug so much as it is a complicated calculation for the rendering engine to determine what will and won't fit into a space. To the human eye it will fit but it's possible the underlying calculations inside Tableau don't see it that way. I find that particularly on dual-axis charts (like yours) this happens more frequently. I've done two things to get around it when it comes up:
Change font family or font size
Put more info into the tooltips so the end user sees the data when they hover.
If you wish to pursue this as a bug, you will need to contact Tableau Support and file a case. They will ask you to submit a twbx file to reproduce the issue.
I hope that helps.
Label -> Font -> Automatic solved the problem for me
You can select individual marks, right click to pop up a menu, and specify whether to always hide or always show the labels for the selected marks (overriding the default behavior)
I have a data entry form. Its properly tab indexed etc. and there are three dropdown menus which automatically unfurl with the on enter event.
No matter how much advice i give to users about using the tab key and keboard and checking what they just input.
they still insist on using the mouse to select values from the dropdown menus
the problem is that in their haste they often make mistakes as a result of using the mouse.
I would like to be able to force users to input into these fields using the keyboard.
the drop down is neccessary for users see the appropriate values for the field because the values will vary based on previous selections.
I have already tried experimenting with onclick events but to no avail.
Is there a way I can do this?
i am using access 2007 many of the users have access 2003.
Based on your comments, I would take one of two different approaches.
If your users are really comfortable with the codes AND know which ones they should use based on their previous selections, then just use text boxes instead of combo boxes. You can still put some validation code in either the Form_BeforeUpdate event or the individual control's _BeforeUpdate event.
If the users are not that comfortable, then I would suggest you have the first field in the combo boxes be the description of the code, not the code itself. So instead of choosing from 101, 102, 103 they are instead choosing from "Small", "Medium", "Large" or whatever those codes actually apply to. If you still wanted to display the codes themselves, you could do that with a separate disabled text box.
Now to answer your actual question. For the record, I highly recommend against using this approach. The simplest way I can thing of to prevent your users from using the mouse to select the combo box, would be to add a Transparent button covering the combo box.
To do this, draw a regular command button over the combo. Set Transparent = Yes, Visible = Yes, Enabled = Yes, Tab Stop = No.
When users click on the combo now, they will actually be clicking on the Transparent button and nothing will happen. The ONLY way they will be able to get into the control is by tabbing from a neighboring control or using a hotkey (via '&' in attached label).
Once they enter the control via Tab and your code forces a dropdown, they will still be able to choose an option using the mouse. But by forcing them to use the keyboard initially, it will make it much more likely that they just stick with the keyboard.
Again--I can't stress this enough--I think this is a terrible, horrible, no-good idea. Please don't use this approach. But you asked a technical question and this site is all about giving technical answers, so there you go...
I have a Crystal XI Release 2 report that my client wants to see on two pages. He wants the report to print the demographic information such as (name, address, etc...) for a person on the first page and the totals for the person need to print on the second page. The first page will include as many rows as will fit and the second page will have the same amount of rows which correspond one for one to the first page. Then the third page will contain a new page of people starting where the first ended.
He basically is looking for printing similar to how Excel prints (and please don't tell me to Export to Excel and print from there).
I came up with two ideas for doing this, but only got anywhere with one. The first was to run two reports (one for the demographic info and the other for the totals) which would be collated together somehow. I didn't get very far with this, but I didn't spend a ton of time researching this so I still think this could be an option.
The second way was to extend the report design to the width of two landscape pages, add my fields, and then change my page size back to a single landscape size before I get ready to print. This way sorta works, but can cause some weird issues. One is that if you try to edit/add a field on the second page when the report size is set to a single page landscape the fields are moved to the far right of the first page which makes sense because I would think that is supposed to be the editable region of the designer so I'd assume you're not supposed to have fields outside of this region.
All in all, the second way works, but I know there has to be a better way to do this. I wanted to see if anyone has had a similar request or have some other ideas on a better way to do this. Thanks
I can't think of an easy way to do this in Crystal.
You could get all hacky on the datasource and duplicate every 20(or however many fit on one page) rows. Then you would set up 2 details sections, one section for demographics and the other for totals. Then conditionally suppress them depending on remainder(pagenumber, 2).
Or you could use a subreport that accepts paging parameters and only returns 20 rows per page. But I'm not even sure if you can link a subreport parameter to the pagenumber special field.
How does your second way work? The extra fields just get printed on the next page somehow? However, the problem is that the fields stay outside the designer when you go back to one page and if you need to edit they all move back inside the designer? Couldn't you increase the page width before editing? That's not too bad if it somehow prints it out correctly every time.
I guess I will mark this as the answer since I still haven't been able to figure out a better way around it. If anyone finds a better way then post a response and if it works I think can toggle the answer.
What I do to get around this is to set my printer to the "Microsoft Office Document Image Writer" and then change the width to the widest it will allow which is 36". Then I put the demographic information from the beginning of the section to around 11" and put the totals stating just to the right of where the first section ended and go for another page width.
Then I make whatever changes that I need to make and set the printer back to the printer I want to use for the correct size. After you do this you will find that the editable area only extends to the first page, but you can see the second page of fields to the right. If you try to edit a field on the second page the field will move to the far right of the editable region which is at the far right of the first page so make sure you reset your printer before making edits.
I think I also had to play around with the width of the detail section on the layout tab of the section expert to get the report to print correctly. I set it to the combined size of the 2 pages for mine to look correct.
I think that this is probably a super rare issue, but if you are having a similar issue, that is how I get around it.
From a design and usability perspective is it best that an edit page mimics the layout of the view page?
Our view page is very dense. The data is tightly packed together, but when editing there are going to be extra controls next to each entry field. If we leave the layout the same it will be overly crowded. Will this cause problems with usability if the fields are rearranged?
It definitely impairs usability. Two hazards of re-arranging fields are:
Confusing users about which field they are editing
Making it difficult for users to find the field they want to edit.
These problems are exacerbated on high-density pages.
There are some times when this is ok. The best example I can think of is where the editor and viewer are different users. Another (more ambiguous) case is a situation where the edit screen needs to be highly optimized for fast throughput.
If possible, you might consider splitting the screen up, or making collapsable regions to give the user (and the screen) a little room to breathe.
In general you want to keep the edit page as simillar as possible to the view page. In general. There are cases where this just doesn't make sense especially if you have to input a lot of extra data that is not shown in the view, which it sounds like is your case.
What I would try and do is make sure you continue to group and order the fields in the same manner as if you were viewing so while they might be in slightly different places at least they would be logically grouped the same.
It depends upon your workflow.
If the user has to go back and forth between edit and view, it will be very confusing to the person, as fields may jump around, they might lose which field they are on, etc.
If your view page is very dense, you might try breaking it up into sections, each with its own edit function. You could have it shoot to its own edit page or be all 'web 2.0' and throw up a lightbox with the section edit form over the view page.
The more that things are similar, typically, the easier it is for a user to use. I don't know what your particular layout looks like but from a general point of view, a crowded view is often hard to look at and cluttering it up with additional controls would make it worse.
As much as I'm not a spreadsheet guy, editing in Excel or similar products is easy because it doesn't clog up the view with lots of controls. The edit panel is the view panel. For my own products, when things are consistent, the users are generally less confused.
I have had a similar problem. What I did was have a View page that lets you see everything, but you need to drill into individual edit pages for logical sections. Within the logical sections the fields are always in the same order (and with the same labels) as on the view page. It's things like this which make your application just feel a bit nicer.
Don't throw everything onto a massive edit page just because they all relate to the same thing in your database model. Break them out into sets that make sense each with 3-7 fields on them.
If they really need to edit everything (like when creating a new thing) then I would go for a wizard approach which steps through through, presents a view-only summary and then lets them save.