Conditionally setting visibility-toggling in SSRS - sql-server

I have a report in SSRS 2008 R2 that lists medications and prescriptions. The prescriptions are hidden unless you click on the medication + box to show them.
Now, in some cases, we don't have any prescriptions listed for a given medication -- they're managed by an external provider, but we want to track their existence anyway. This leaves me with the case where we still have the + box, but clicking on it shows an empty line. Is there any way to conditionalize the ability to toggle the line's visibility? Thanks.
ETA: Ok, I just figured out a partial answer to this. I had a spare textbox available, so I added the text "Show scrips" to it and made that the controlling box for the toggle, and then swapped its own visibility depending on whether there were actually scrips to show. However, this makes the borders go away, as well as the contents. Short of removing all the borders (which might be the proper solution, actually), any suggestions?

Here's a thread that discusses this issue: you basically put the +/- into another column and show/hide that based on whether there's data.

Related

SQL Report Builder 3.0 - Failed to preview report

I have looked but have not been able to find another posted question that matches my scenario.
I am replicating a report from an old DB and rebuilding it using a new DB, so I'm simply copying the old report elements and pasting them into a new report template and modifying as needed. I've gotten to one part where the error I'm getting is as follows:
The Color expression for the text box ‘Textbox94’ refers to the field
‘Gallon_Qty’. Report item expressions can only refer to fields within
the current dataset scope or, if inside an aggregate, the specified
dataset scope. Letters in the names of fields must use the correct
case.
I have looked everywhere I could possibly think to look to see where this issue is hiding, but cannot find where this textbox is 'referring' to anything. Since it appears to be specific to this textbox, I presume it is specific to the text box properties of that text box, but it seems I'm mistaken. For added clarity, what I have checked includes every menu option within the text box properties (General, Number, Alignment, Font, Border, etc.) and every fx (function) button to ensure nothing was hiding (that's gotten me before). I have compared with another report element that works similarly and cannot find where the problem is. Any tips on where else I might check to uncover the root of this issue? Happy to provide screenshots if it will help, just let me know.
Side note: I can't thank you guys enough for all the help I've gotten on here!
I discovered where the issue was.
Text Box Properties>Font>Color>fx box
This is where the value was hiding. Hope this helps someone else.

MS PowerPoint CheckBox remains linked when slide is duplicated

Hoping you can help me as I have searched a lot of forums and did not find the same question, never mind the answer I need :)
I have a power point pack which I have put together. It is built to be a template for my team to use repeatedly and is set up using slide masters to control the layout. Each layout slide in the slide master includes two checkboxes to identify either a pass or a fail. My problem is that when you insert a new slide (by either duplicating an existing slide or adding a slide from the slide master layout), and change the checkbox value it also changes on the other slide. Is there a way either using some quick VBA or otherwise to stop this from happening and break the link between the two slides.
Any help would be really appreciated.
In a weird way, this is reasonable behavior from PowerPoint, though it certainly does seem bizarre.
Shapes on a master layout appear on any slide based on that layout. Though they appear on the slide, they're not editable on the slide; it's as though the slide were a clear layer above the layout, one that you can add more stuff to but that you can't "penetrate" to get at the stuff on the layout below.
Placeholders are a special case and so, apparently, are ActiveX controls like your checkboxes, which DO allow editing. So what's happening is that when you change a text box, you're changing the text box on the layout, not on the slide itself (the checkbox doesn't even exist on the slide ... you can't select and move it in normal view, for example, unless you go to the layout in Master view).
When you change the checkbox, you're changing the one on the layout, and since the checkboxes appear on any slide based on the layout, when you change the checkbox, you're changing the one on the layout, ALL of the slides based on that layout get the changed checkboxes.
Some mildly tricky VBA could look at each slide and if it's based on the layout that contains the checkboxes, COPY them to the current slide from the layout and finally make the checkboxes on the layout invisible.
The simpler solution might be to supply a sample slide with the checkboxes ON the slide and let the users copy/paste it into their presentations.
[later]
I've reported this to MS as not so much a bug as a design oversight; the behavior may make sense, but it's not useful and can mislead users (as you well know).
I'd suggest that you visit https://powerpoint.uservoice.com and suggest that ActiveX objects on masters/layouts behave more like placeholders ... spawn new instances of themselves when a new slide based on the layout is added rather than letting the user THINK that's what's happened.

adding checkbox to ssrs tablix that will be manually clicked

I have created a stock taking report in SSRS 2008. I have also added an extra column in the tablix.
The extra column I added is a column I want to have the option to manually click on the checkbox if item is in stock.
I have tried using the wingdings option using the below expression:
=iif(Fields!Expr1.Value,chr(252),chr(251))
However the result I get is not the desired result, because I get about 6 winging characters back instead of the check and uncheck boxes I required
How could I go about fixing this ?
One option is to use an Indicator, but I've preferred to use images for similar situations. Embed the two needed images in the report and switch between those dynamically. (You can make standard images of your characters in MS Paint or Paint.NET.)
Images have the disadvantage that they don't print with high resolution, but they do render on most devices (not .csv) and you don't need to worry about installed fonts on the server.
As far as fixing your immediate problem, try changing the "Markup Type" for your placeholder (Placeholder Properties -> General -> Markup type.) It sounds like something is trying to generate HTML when it shouldn't be.

wpf / silverlight textbox filter design

I have a list that the user can filter in several ways. two of which lend themselves to combo boxes and two that need to accept user input. For example, one textbox allows the user to type in any part of a list item's description, and the dialog will only present items whose description contains the text entered.
It is a dialog 'picker' type of window, so space is at a premium. I'd like for the text boxes not to require a traditional label. Instead, when the dialog is first invoked, the label (ie, "Description") is grayed out, centered, and in italics. Maybe a tool tip to further make it obvious to the user what it's for. When the user starts to type, the faux label disappears and the entered text is normal left aligned text.
Does wpf / silverlight have any native support for doing something like this? I guess it could be a combination of styles and eventing. I'd rather not invent any wheels that might be out there (I got the idea specifically from looking at Tortoise' "Show Log" window, but I've seen it before).
Does anyone have any sample code they can share to do this? Or a an alternative idea that also saves space and simplifies the layout?
Cheers,
Berryl
Kevin Moore's InfoTextBox, which is part of his Bag-O-Tricks is the kind of thing I was looking for, almost exactly. This is also the 'watermark' (great name - I would have found this sooner if I had known that) text box from another post.

Best way to show screens to user on application

I'm developing a Winforms application which has been running for years with an explorer view (TreeView left, screen right). I means that:
All the screens have an hierarchy organization
All the nodes on TreeView have one and only one screen related.
A screen gets activated when a node on treeview gets selected.
One of the advantages is that the user has an ordered stucture and one of the inconveniencies is that with hundreds of screens the user gets confused.
I see other options: use classical menus, use tabs or a mix of everything.
Any advice for a good way to show a lot of screens to user in a user-friendly way?
Update: I'm changed "hundreds screens" by "a lot of screens". The most important thing is not show all at time but that the user can find what they need easily.
Update2: In this proposal, the user only see one screen at time.
Update3: I'm talking about handling multiple screens not showing multiple screens. No MDI, only one ontime.
I have used other applications similar to this is the past, and the major problem is trying to find the exact screen you want. There are two common solutions to this problem, shortcut codes and favorites menu.
With the shortcut codes, allocate a short code (5 or 6 characters) to each screen. The user then inputs this shortcut code into a text box which will then jump to the correct screen. Users will create their own list of often used codes.
For the favorites menu, allow users the ability to be able to create their own menu list in the structure they want. They will find things easier, if they organize it themselves.
Why do you need to show so many seprate screens at once? Why not just show the screen for the currnetly selected node, why are all needed at once?
If it is all tabular data is is probably too much to be consumed all at once, if it is graphical data, could it not be combined?
There may be a valid reason to show all the data at once or there may not, hard to tell from what is provided in your question. With that said, better to keep it simple than overload the user. MDI apps are never easy to use.
Tabs may work for a small set of items but still is not a good UI for hundreds of items.
If you are only showing one element at a time, out of hundreds possible on the tree nodes, then that is fine. The one screen showing at a time would be contextual to the item selected as the user moves through the nodes. Think of the Outlook approach where what is selected in the left pane is displayed in the right pane in whatever form fits the data being displayed.
Have you considered the Office Ribbon?
The Ribbon gives you a lot of flexibility on how to show and
organize functions and it's highly visual.
Here is a good link about the Ribbon and also here
To use the Ribbon you have to license it from Microsoft. You can do that online.
Providing the user with ketboard shotcuts is usually a good thing too.
I also like to provide the user with an "autocomplete" field on the menu
so that they can can find the function by name (or part of it) and be
able to navigate directly to where they want to go.
I general I find trees to be a bad idea, especially if your "hierarchy" is of a small fixed depth.
If you have a small fixed depth, consider replacing the tree with a list. At the top of the list can be drop-downs for filtering based on the node-level properties. It will use up less screen real-estate because it is vertical-only, with no horizontal component.
Clicking on an item can display it in the view (like currently), but it may be a good idea to allow a user to double-click on more than one item which could launch more windows, or tile with the existing displayed items. (I am assuming that currently, the user only sees a single detailed view at once in any given window.)
Actually, it’s hard to beat a hierarchy for organizing large numbers of items. I wouldn’t favor a classical pulldown menu for vast numbers of windows because it would be even harder to keep track of where you are than in a tree (e.g., a tree lets you look in multiple branches at once). But here’s a few alternatives:
I’m not clear how you ended up with so many windows, but maybe it comes from combinations of classes, views, content, and detail, or maybe it comes from using a task-centered UI structure for something far too complex (I’ve more on that at http://www.zuschlogin.com/?p=3). For complex apps, you want a different primary window for each significant class of data object (e.g., invoices, employees). These are listed on one menu, and typically there’s few enough (15 or less) that it can be single non-cascading pulldown menu. The content of each window is set by a separate menu, perhaps by a menu item that opens a dialog that may include a list box (like an Open dialog) or other controls for querying/searching. The “view” of each window (how the data objects are shown, e.g., table versus form) is set by menu items in the View menu. Details for any given object in a window can be shown in a separate pane within the window in a master-detail relation, essentially turning you data objects into a menu for details. A single window can have multiple detail panes for the user to open and close to select the specific detail to show. Tabs may also be used within a single pane to fit subdivisions of content.
You say it’s not important to show all window options at once, but often showing all options at once makes it easiest for users to find what they need. Maybe you need a “home” window that lists all the other windows in organized, labeled, and separated categories. This is will be easier to use than the tree if your users select a window then stick with it for most of the session. Your tree is better if there's frequently selection of windows throughout the session, owing to the overhead of getting to the home window. If all windows/options don’t fit on a single home window, then show only selected common windows for each category on the home window and provide a button or link to show an exhaustive list.
If you’re talking 100’s of windows, maybe you should have Search, perhaps in addition to a menu-based browse approach to getting to a window.
In any case, providing easy access to the few most commonly used windows is a good idea. Such windows can be explicitly selected by the designer, based on user research, or selected by the the user (favorites), but it also typically works well to make it automatic with an algorithm that uses some combination of frequency and recency of use.

Resources