I have been extremely pleased with OpenEMR since I configured it for our office a few months ago. With only a few minor issues here and there (which have all been resolved), OpenEMR has been a dream to work with compared to the expensive EMR software we previously used.
There is one graphical issue preventing me (and my OCD) from upgrading to v4.1
The above screenshot is a comparison of our current installation on the right (v4.0) to the official demo on the left (v4.1). There seems to be very noticeable clipping on the new calendar screen. Is this an issue anyone else is having? I have confirmed this issue on both Firefox 6.0.2 and IE 9.
Any input on a potential fix or how I can submit this issue to a bug database would be appreicated.
There is still some “overlap” when the screen width drops below a certain level, but I think it’s easier to tweak from here and overall a better approach as if you want to run at a narrow size you can easily change the width percentages in ajax_templates.css at your convenience.
This looks way better, so I committed it to sourceforge (master branch for now; plan to also take over to rel-410 at some point after more testing and include in next 4.1 patch).
For the calendar, regarding functionality, main issue I think now is that the ‘>’ to go to next month gets lost when width is too narrow. Perhaps could prevent this better if moved the ‘>’ character over to the left one space; or what may be even better is to put the back month and forward month as buttons/characters above the calendar; so could then center them closer and avoid any overlap happening to them.
Actually, forget all my nonsense above regarding next month and last month stuff.
Should be able to protect the width of the left div by using the min-width property (rather than px for this type of stuff, I generally use em); if set a good min-width , then should avoid the calendar ever getting clipped/overlapped.
If I set a min-width, when the screen width drops below a certain size the calendar on the right gets pushed to the next line.
I might try setting min,max and default sizes to the right calendar. Just thinking aloud here. Trying to get it to work decently for tablets.
Sorry I haven’t been able to actually look at the code. But my thoughts on something like this (where there are two columns like this that need to stay together) are to consider the following:
<table>
<tr><td>
<div left column>
</td>
<td>
<div right column>
</td>
</tr>
</table>
And then would set a min-width for both the left column and right column to ensure they never get “too small”. Guessing the min-width em on left will be about 12 or so and the min-width em on the right will be about 20 or so.
I’ve almost found a good solution. It displays nicely on my tablet in both portrait and landscape modes, and it also displays in a browser with width as low as 480 decently. (The top title bar starts to behave badly at such a low width, which is a different issue.) Hmm… it tests nicely on firefox and chrome, but it doesn’t seem to work right on IE9.
but to explain more specificially. The bottomLeft Div (which I added with the last commit) and the bigCal div are now both wrapped in a new div id=bottom. The bigCal DIV’s CSS for layout is basically only overflow:hidden. This makes it use up whatever remaining width the bottomLeft doesn’t use.
Here’s a pseudocode description of what it’s like, I might skip a couple details that aren’t in the commit, as I’m typing this up independently.
.HTML code
P.S. I’ve read many an article on the perils of table based layouts, and I wanted to learn some more CSS/float/block tricks, and like I mentioned early I tried with a table before, but couldn’t get it to work quite right.
mcgillcutty When we had the same issue, we noticed that Hide Menu would fix it so we figured it was related to screen width and took out the width restriction put in DIV style tag
style="width=33%;"
Not sure why the date block is limited to 33% but taking it out makes it easier.
Also with the limited real estate of the tablets, it does not make sense to have the blank area on top. But perhaps there is some reason for that as well…
Looks great on Firefox, but agree broken in IE9. IE can sometimes be a pain with CSS(marked improvement since IE6 days, though); here’s a nice resource to check on support for CSS commands in all IE versions: http://msdn.microsoft.com/en-us/library/cc351024(v=vs.85).aspx
Agree that a global CSS solution (if you can get it working) would be much better than having to resort to using table tags.
Hi Yehster,
It looks great. Just committed this to sourceforge (and will include it in the 4.1 patch). Only request is to add a GPL license/copyright to top of the IE css page (see other scripts for examples). Also, you’ve done a lot already, but am wondering if it would also look better to decrease the width of the calendar date label at the top of the calendar; it seem to wrap the text of the date label with still a lot of space to the right of it.
thanks for the contribution,
-brady
@brady,
I think you are referring to the same issue that mdsupport talked about earlier with dateNav having it’s width restricted to 33%. It was hard coded in each of the individual templates (which is the wrong place for it anyway). I removed that and it seems to look much better.
I’m also cleaning up the code to conditionally include the IE css page. (it would have broken before if your install directory wasn’t openemr).
Will update with new code when it’s ready.
Couple more calendar changes. I fixed the duplicate DOB in the tool tip in the Day view. I also added the patient name for appointments in the week and month views.
Changed my hardcoded location for the ie specific style sheet to use webroot instead.
as for the GPL for the css. I just deleted my autogenerated authorship from before, as none of the other .css files seem to have GPL/license comments. Seems like a waste of bandwidth in this case. It’s less than 100 characters of actual code
