Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Textbox transparancy 3

Status
Not open for further replies.

Koen Piller

Programmer
Jun 30, 2005
841
NL
Hi,

I would like to have a textbox with transparent background. So:

SetBackstyle = 0
Placed this box over a label with a format indication dd-mm-yyyy
Label.Backstyle = 1
Yet the label is not showing, what am I missing here?

rgds,

Jockey(2)
 
Interesting. I've been using this product since the first Alpha release and it never occurred to me to even try this.

I thought maybe Themes were interfering, but no. You can get transparency in the designer by setting .Themes = .f. but not when the form runs. Hmmm.

Hopefully someone will know the answer. [bigears] This is why I love reading these forums ... you learn stuff just by observing.
 
Dan,
Indeed my too, working since dBaseiii, never ever had use for it. Do you have an other galant solution to show users to type-in the correct format?
The tooltip is already populated but it seems it pops too late to be for any use here.
Regards,
Jockey(2)
 
The textbox is transparent, but not when you edit its content.

If the textbox isn't linked to a field (controlsource), a simple solution for your request is to use the Nulldisplay property.
When the textbox value become empty, change it into Null.

Code:
PUBLIC ofrm
ofrm = CREATEOBJECT("MyForm")
ofrm.show()

DEFINE CLASS MyForm as Form
	ADD OBJECT txt as textbox WITH Value = Null, NullDisplay = "Find...", ForeColor = RGB(120,120,120)
	ADD OBJECT txt2 as textbox WITH top = 50

	PROCEDURE txt.interactivechange
		IF EMPTY(This.value) 
			This.Value = Null
			This.ForeColor = RGB(200,200,200)
		ELSE
			This.ForeColor = 0
		ENDIF
	ENDPROC
ENDDEFINE


Respectfully,
Vilhelm-Ion Praisach
Resita, Romania
 
Vilhelm,
interesting approach, thnanks.
Finaly I have decided to work with a label.A label which is on top of the receiving box
In lostfocus of controlling box the label is set visible upon condition.
in gotfocus of the receiving textbox the label is conditionaly visible.
Rgds,
Jockey(2)
 
Using Nulldisplay is a nice way, but that has a too broad effect on any display of NULLs, if you ask me. There once was a fix to make the grid show tooltips, which was a RC version bug of VFP9. It was using the general Windows API functions to display tooltips and you could also set this to show tips immediately.

The best way to go about date entry is using some datepicker or setting a default date, like today, the textbox also has date format properties you can set different to the general date settings. With today as default it should become clear what to enter. Simply set value to DATE() or put in =DATE() in the property window for the textbox.

Bye, Olaf.
 
I realize now it's easier to do the inverse, if you still don't like to simply set a date. Put a transparent label on top if the textbox. Set Forecolor to a light grey. In Click set Focus to the textbox or simply forward all mouse events via Bindevent to the textbox below.

Bye, Olaf.
 
I'd just set the textbox's value to {} and let it go. Once it's set as a date, it'll only accept a date.
 
Dan,
I suppose you are correct, but again you have those stupid (?) users, they type-in 08-12-2015 or they type 2015-08-12 what is it? You tell me.
I prefer to make it as simple as possible and give them dd-mm-2015 as a hint.
Rgds,
Jockey(2)
 
Users are sort of used to web pages that put this sort of hint just above the textbox.
 
Jockey,

if a value is set you can't input something not working anymore. If the date format of the textbox is dd-mm-yyyy and you set it to DATE() - as I suggested - or to {} - as Dan suggested - users can't type in 2015-09-21 anymore. That won't be valid. It's the first hint you got to work this way. What may go wrong still is dd and mm order can go through.

Your initial idea to hint with a text within the textox isn't bad, but you won't get the textbox transparent to show a label underneath. You can put a label on top though, and make it transparent. Mouse evnts can be forwarded to the textbox via Bindevents. Simply reread what was already said.

Bye, Olaf.
 
Olaf,
I believe you are correct, however I have placed the label over the textbox, it will disappear on mouse-down, if I leave you leave it visible the whole thing has a tendence of being unreadable.
The idea of {} is 100% correct, users can't type-in an invalid date but 08-12-2015 can be 8th dec or 12th august, there are funny clowns walking around, you know as well as I do, so I tell them what format I expect, if they than still type grubbish, let it be.
Thks for your thoughts,
Rgds,
Jockey(2)
 
>I have placed the label over the textbox, it will disappear on mouse-down
How would that happen?

What did you program in the click or mousedown? If you did nothing the label would stay where it is.

Of course you can't leave it visible, you use several bindings and some code in the interactive/programmatic change of the textbox sets the label.caption = "" when the textbox value is not empty.

There is no protection against vald dates meant in a different manner, you can just respect the OS settings, which most often (but also not always) reflects a users habits and expected format. SET SYSFORMATS ON copies some of the OS settings including date settings. Otherwise explicitly put the format as a label above or below the textbox (in y direction, not in z direction).

A datepicker (also allready suggested) also makes very clear in which year and month you pick a date.

Overall, you should have already done this a thousand times, makes me wonder how you coped with this topic of date entry so far.

Bye, Olaf.
 
Hi,

<What did you program in the click or mousedown? If you did nothing the label would stay where it is.
This.Parent.lblFormat.Visible = .F.


F.y.i. This is a legacy application which I was requested to correct some errors and some new requirements.
One thing was a searchform which prompts for a all fields (combobox) in which you can type in a searchforin a textbox. One field, datetime, called date (GRRR), users typed in a data in all kinds of formats and never ever found a record.
I changed the logic, converted the datetime content into a date part only and figured to show users which format was requested to be used.
Found in textbox the background =0 and to my suprise this did not have any effect, that's why this question here.
The datepicker would also be a good solution, I believed the label would do.
Anyway to much hazzle for such a small, still enoying, problem.

Rgds,
Jockey(2)

 
Code:
This.Parent.lblFormat.Visible = .F.

You might just consider moving it out of the way instead.

Code:
This.Top = This.Parent.txtWhatever.Top - (This.Top-2)

Or maybe start it there and leave it there and just stop fiddling with it?

Anyway to much hazzle for such a small, still enoying, problem.

I've always said if a problem is inordinately difficult to solve, perhaps you're solving the wrong problem. [pipe]
 
Jockey2,
The upside to a date picker is you can put it on a button next to the field, but keep the button small. And this is something people are used to seeing on web applications where reservation systems are used, like for rental car or airline or hotel bookings. So it shouldn't be a foreign concept to most users. Get an icon that looks like a calendar (just google for that) and make a button that is the size of the icon, put it next to your field, and put the date picker on the click event. Easy, and aligns with current user interface experience in other appliations.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."[hammer]
 
Just because it's a legacy application doesn't mean you can't apply how you do date entries in your application.
The only thing not ideal with setting the value to {} or DATE is users may type in some low day of some month which really means the inverse. But why do they do? Because they are used a typical format for their country and if you simply apply SYSFORMATS that's giving them what they are used to. You might change tooltip to this:
Code:
Set Date LONG
This.TooltipText = Dtoc(Date())
Set Date SHORT
Or display that aside of the textbox. They'll see what the entered date means. Also in many cases they'll get an invalid date and over the span of some weeks they'll surely learn the date format typical for their own country. Enforcing a valid date means they already can do less of what they did in the past and the only thing to learn is where date and month are entered. They'll typpically know that, if you respect SYSFORMATS, don't they? Eve if you or the pp orces some untypical format, if you init with DATE() they'll recognize this is being today, and aside of 12 days a year, the 1/1 to 12/12 they'll see where the month has to go.

You're the one not satisfied by our simple solutions, so don't complain that you make so much hazzle.

Bye, Olaf.



 
From a usability standpoint, don't do this. I've lost count of the number of web forms where the prompt disappears as soon as a textbox gets focus. It's usually on a login form and I have to idea if they want a username or email address.

Craig Berntson
.Net MVP, Author, Tech Presenter
 
Craig,
please elaborate, don't do what? Don't put a lblFormat over a textbox, to be disappeared upon GotFocus / MouseDown ?
Rgds,
Jockey(2)
 
I'm not Craig, but I think this is what he meant to say. In HTML5 you now have the placeholder attribute of html form controls and that works the same way, a light grey place holder text for what to enter. I disagree that it's a bad UX under all circumstances. It can save the space for a label, it is visible immediately and the problem you forget it when you enter the control is not a problem I see iin the UX, short memory? Really that short you can't remember you're asked for login name or email? You can clearly read what to enter right before entering, if you tab into the control before you read the placeholder text, is that really the site's problem?

I have a simple feedback form at the homepage I'm about to publish soon, and it make use of both styles. I use labels for the fields "Your Name" and "Your Mail Address" but placeholder in the textarea "Your Mesage", which disappears when you enter it. It's the largest input control, it is quit intuitive you enter your message body in there.

Well, the usual old style design is a label above or aside of each input control, and that might have the caption "searchdate (dd-mm-yyy):", I'm also not the first proposing this, but even a placeholder text within a textbox doesn't mean you never can reread the tip text, such controls still can have a tip text and the alt or title attributes of html controls even can show immediately. Also you can tab back and see the placeholder text again.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top