I know I've seen a list before of the predefined VisualStateGroups and states for a VisualStateManager, including CommonStates, CheckedStates, etc., but I can't seem to find it again.
Does anyone know where such a list might be found?
EDIT:
I'm catching on to the fact that lots of these obvious reference lists are built in to Expression Blend, which Microsoft apparently assumes everyone will buy. That or they hope that by not making this stuff easy to find, we'll cough up the money and buy the thing out of sheer frustration.
I'm a contractor for the federal government, and we've ordered EB, but of course it will take months for the order to get approved and processed and delivered. In the mean time, my trial download has long since expired and I'm stuck here in hand-coding land (where I honestly would prefer to stay). In the mean time, any help is appreciated.
I don't recall coming across any list of "predefined" groups. However the place where you can find lists of groups in close proximty is in the Control Styles and Templates documentation. But for general reference the list of Groups shared by multiple controls found here are:-
CommonStates
FocusStates
PopupStates
ValidationStates
CheckStates
Bizarely RadioButton has a group called CheckedStates not CheckStates. Basically the group names really only have meaning within the control so its not technically that important what they are called. However it certainly would makes sense to re-use group names that describe a common domain of states.
Related
In our group, we have to model the state "needs discussion" for Bugzilla.
Therefore, a custom RESOLVED - to be discussed status was introduced. The appropriate group of people searches for issues that have this sort of "resolution" status and discusses these offline.
In my opinion, this is not the proper way as the bug/feature clearly is not resolved if there still is need for discussion. This is also reflected in the standard life cycle of a bug. It is sort of misleading, as "needs discussion" items show up in your list of resolved bugs.
One way I can think of, would be to make a sort of "virtual user", representing the group that has to be involved in the discussion. This has the advantage, that one can search for the bugs easily. One could also setup a mailing list to notify the users.
I wonder how one can appropriately model this needs discussion state of a bug in Bugzilla 3.0.x. (And: what is the Mozilla-way solution?)
As with any software system there are a multitude of ways to address your need.
Before you start with mechanism it would be good to think about requirements.
Do you want bugs the need discussion to be counted as "open" still, or do you consider them "resolved". Do you even collect those types of metrics?
The requirements I derive from your question are
Don't want to see them in normal searches
Do want to be able to see them when looking explicitely
Need to be able to finalize the discussion, and "bring the bug back" to normal
Would like to notify people that there is a discussion to be held
Would like the bugs to not look like they are resolved
If those are really the requirements, and you don't care that "for discussion" bugs are showing up as resolved for metrics etc, then I think what you have is probably good enough, except for point 5.
Some other alternatives
Create a "Discussion" product (or component).
Create a custom lifecycle (I wouldn't recommend that though).
Assign to the "Discuss-me" group/user
Use a "super bug", and mark the bugs a blocking the "Discussion super bug"
Create a "discuss this issue" bug, and mark the bug as blocked by the discussion (this reflects reality the closest, but that doesn't make it the best option).
But, as I say, think about what you're trying to achieve first, and then choose the mechanism based on that. There are different trade-offs around the amount of bug-fiddling you have to do to make them all work :-).
Me and my colleague are developing an ms access based application. We are designing and coding different pages/forms in order to divide work. We plan to merge our work later. How can we do that without any problems like spoiling the design and macros? We are using Ms access 2007 for front end and sqlserver 2005 as the datasource.
I found an idea somewhere on bytes.com. I can import forms, reports, queries,data and tables that I want.I'm going to try this. However, it's just an idea.So, need to study this approach by trial and error techniques.
The most important requirement is to complete the overall design before you start coding. For example:
All the forms must have the same style. Help and error information must be provided in the same way on each form. If a user can divide the forms into two sets, you have failed.
The database design must be finished with a complete, written description of each table, its relationships and its attributes.
The purpose and parameters for each major macro must be defined. If macro A1 exists only to service macro A then A1 is not a major macro and only A's author need know of its details until coding is complete.
Agreed a documentation style and detail level. If the application needs enhancement in six or twelve months' time, you should be able to work on the others macros and forms as easily as on your own.
If one of you thinks a change to the design is required after coding has started, this change must be documented, agreed with the other and the change specification added to the master specification.
Many years ago I lectured on (Electronic Data interchange (EDI). With EDI, the specification is divided into two with one set of organisations providing applications for message senders and another set providing applications for message receivers. I often used an example in my lectures to help my audience understand the importance of a complete, unambiguous specification.
I want two shapes, an E and a reverse-E, which I can fit together to create a 10 cm square. I do not care what they are made of providing they fit together perfectly.
If I give this task to a single organisation, this specification will be enough. One organisation might use cardboard, another metal, but I do not care. But suppose I ask one organisation to create the E and another the reverse-E. How detailed does my specification have to be if I am to get my 10 cm square? I would suggest: material, thickness and dimensions of the E. My audience would compete to suggest more and more obscure characteristics that had to match: density, colour, pattern, texture, etc, etc.
I was not always convinced my audience listened to the rest of my lecture because they were searching for a characteristic that would cap all the others. No matter, I had got across my major point which was why EDI specifications were no mind-blowingly detailed.
Your situation will not be so difficult since you and your colleague are probably in the same room and can talk whenever you want. But I hope this example helps you understand how easy is it for the interface between your two parts to be less than seamless if you do not agree the complete design at the beginning. It's the little assumptions - I though you knew I was doing it that way - that will kill your application.
New section
OK, probably most of my earlier advice was inappropriate in your situation.
So you are trying to modify code you did not write in a language you do not know. Good luck; you will need it.
I think scope is going to be your biggest problem. Most modern languages have namespaces allowing you to give a variable or a routine as much or as little scope as you require. VBA only has three levels.
A variable declared within a function or subroutine is automatically private to that function or subroutine.
A variable declared as Private within a module is invisible to functions and subroutines in other modules but is visible to any function or subroutine within the module.
A variable declared as Public within a module is visible to any function or subroutine within the project.
Anything declared within a form is private to that form. If a form wishes to pass a value to an outside function or subroutine, it can do so by writing to a public variable or by passing it in a parameter to a public function or subroutine.
Avoiding Naming Conflicts within VBA Help gives useful advice.
Form and module names will have to be unique across the merged project. You will not be able to avoid have constants, variables, functions and sub-routines which are visible to the other's functions and sub-routines. Avoiding Naming Conflicts offers one approach. An approach I have used successfully is to divide the application into sub-applications and, if necessary, sub-sub-applications and to assign a prefix to each. If every public constant, variable, function and sub-routine name has the appropriate prefix you can simulate namespace type control.
I have a hierarchy of stuff I want to display (at the same time) in both outline view and a custom view. Sort of analagous to the Buck and Yacktman (Cocoa Design Patterns) example in CH. 29, but with Outline instead of Table. I'll most likely have a detail view available also.
I've only used NSTreeController with a single outline view before. Now I have found that "arrangedObjects" aren't what one would like them to be. Also found that (for some reason) all the 'canInsert' and it's relatives have value NO (for some reason I can't find (or find with google)). So so far, it appears that NSTreeController is little help in coordinating my two views. (By the way, I've always had my add, delete functions work directly on the model in the past.)
it seems to me now it would be better and simpler to go back to using a data source approach, and use an architecture more like Buck and Yacktman's figure 29.4 (page 357) with a handmade mediating controller.
This has been hanging around for quite a while with no takers.
Just to close this out:
I've tried both NSTreeController and data source versions. Currently, I'm sticking with data source, since it seems to give me more flexibility.
-- The program I'm working on has been very much experimental, trying a number of different things. A secondary goal is to make an application I will find useful, and ternaryily :-) maybe make a cleaned up version for distribution.
In a project I'll be working on soon there will be a need to generate avatars. The generation process will be one of those where the user can select different heads, hairstyles, clothing, etc. Some items will also be unavailable at first and will have to be earned or purchased.
I already have a fair idea on how to do this, but since it is a nontrivial amount of code, it would be nice to see working examples of code. Ideally I could just take a script and integrate into my page, but just gathering ideas from other people would be good too.
I'll be working with PHP, but examples in other languages are welcome too.
Added: To clarify, I don't mean a random avatar generator (or one that generates an avatar based on some hash value). A random avatar generator is subtly different from what I have intented. In a random avatar generator the programmer-artist has a much greater say of what goes where. He can carefully pick out pieces that will not conflict with each other, and he can discard those that give him trouble.
In my case the avatar generator is more like this. The user chooses which head to use, which hairstyle to apply, which piece of clothing to use, etc. There are way more pieces there, with artists adding new ones every once in a while. It's much harder to test how pieces will or won't fit together. Sometimes more advanced blending is required (like a hat would have a part of it in front of hair, and part of it behind the hair). Etc.
[EDIT: Revised answer to updated question]
I think that it's primarily a matter of designing the parts accordingly. You have some basic forms (male, female, tall / small, etc.) for which you have stylesets (e.g. hair) designed to match and align perfectly. Solving this algorithmically instead is probably a bad choice in terms of workload and probably not necessary for non-animated figures.
However, maybe you'll need some additional alpha-channel/transparency masks or something for combining head, hair and hat.
Other than that, these parts would have to be combined layer for layer like Monster ID.
infernowebmedia.com
They sell a cheap and fully functional website code to make your own avatar site.
I've got a WinForms client-server app that displays various offers in a list. Every user (client) has a "rating". An offer consists of various data including a minimum and maximum rating. If a user's rating does not fall in that interval, he should not be able to take the offer.
Of course I could just perform some server filtering and send a list of offers prefiltered for each user to the client application. But that would surely, and rightfully, lead to confused requests "Why isn't this offer showing up? I know it exists, it shows up on [other user]'s screen."
How should I handle this? My favorite solution so far is to grey out the offer and add a tooltip "You can't take this offer because your rating is too high/low" while displaying greyed-out offers at the bottom of the list to leave the actually valid offers easily visible on top of the list.
A disabled option tells the user:
The action is possible.
Just not right now.
But the user can make it possible.
Unless there is some simple action the user can do to change his or her rating (e.g., by selecting some other controls in the same window), do not use disabling and do not show the offers. Disabling may confuse some users who will then hunt around the window for something to do to enable those offers. It’s a great idea to use a tooltip to explain disabled objects, but that’s not a standard and not all users will think to hover the mouse over a disabled option (Why should they? It’s disabled).
Including offers users can’t have, even when disabled, clutters your display, forces more scrolling, and distracts the users from the offers you actually want them to consider. Furthermore, showing unavailable offers can come across as taunting (“ha, ha, your rating isn’t high enough”) and may diminished the perceived value of the available offers by comparison, resulting in lower user satisfaction.
It seems unlikely to me that users are going to go around comparing the offers on their windows, but maybe you have user research saying they do. In any case, you should label the list of offers to make the criteria clear (e.g., “Offers available at your rating” may be sufficient).
If you want to encourage users to increase their ratings, then maybe include something advertising the benefits of an improved rating. For example you could have a link "-Improve your rating- by four points and get -five additional offers-." The first -link- tells users how to improve their rating, while the second lists the offers as a motivator. The latter link should only be there if the offers will still be available if the user actually succeeds in getting four more points.
That sounds like a good way to do it.
As a slight improvement, if it makes sense for your application, you might consider including the actual numbers in the tooltip, e.g.:
This offer requires a rating between 5 and 8. Your rating is 4.