|
|
Hi guys
After reading some MSDN I still have some things I don't understand.
Having an application with the folowing structure
class MainApplication (thread handling UI controls)
class CModuleA -> (starts a thread thWorkerA)
class CModuleB -> start a thread thWorkerB
here are my questions:
1. From thWorkerB I raise an event intended to be caught by subscriber CModuleA class.
Inside CModuleA it is the handling event funtion.
The execution of the thWorkerB thread remain blocked inside the eventHandling function from CModuleA until it finishes?
2. How is exactly this send event handled? In what context is it done?
3. The Invoke method should be used to execute delegates on the current UI thread, which chage controls.
This Invoke function could be used in other cases, not involving UI controls? (similar situations)
modified 19-Jan-12 4:05am.
|
|
|
|
|
1. From thWorkerB I raise an event intended to be caught by subscriber CModuleA class.
Inside CModuleA it is the handling event funtion.
The execution of the thWorkerB thread remain blocked inside the eventHandling function from CModuleA until it finishes?
Yes. Unless you delegate execution to another thread, event handlers run in the thread from which you called them. An event handler should never do anything which will take a long time for this reason (except in cases where you are happy for that component to have its queue stalled); you should post messages onto a queue which is handled by another thread, or something similar, and return as quickly as possible.
2. How is exactly this send event handled? In what context is it done?
Methods called through a delegate are in the same execution context as the method from which they were called, similar to a normal method call.
3. You can use Invoke to execute across threads if you have a Control to call it on, or you have a Dispatcher to hand (WPF). If you don't want it to still block, though, you should use BeginInvoke (generally you can do a fire-and-forget and not bother with EndInvoke as you don't need the return value).
In a pure component situation, where you don't have any UI related infrastructure, you should handle the cross thread execution yourself. As I mentioned above, a good way to do this is to have a thread which watches a queue, and have the event handler post a message onto the queue for the handler thread to deal with. You can use WaitHandles (i.e. AutoResetEvent) to notify the thread that it should wake up without doing 'hot waiting' (i.e. checking the queue in a loop).
Alternatively you can spawn new tasks and push them into a ThreadPool or, if using .Net 4, use the Task Parallel classes in the Framework. Both of these mechanisms essentially run a queue and multiple handling threads pulling tasks off them.
|
|
|
|
|
ok, thanks!
Still I am wondering how this messaging(event sending) between classes is implemented.
(like a function call, or like messaging in a separate thread or context)
but this is not so important.
|
|
|
|
|
Hi
I'm having a weird bug in my application. This is my first time in this forum I hope you can help me because this bug is making me crazy.
It's a desktop application where I have a form with some MaskedTextBox in it. The goal of these text boxes is allow the user to introduce values with format "000.000".
When the user modifies the textbox, the value is stored in a internal variable and until then everything works fine. The problem appear when the application reloads the textbox control from the variable. In my computer the value is retrieved correctly, the application shows in the text box the same value the user has introduced before, but in some computers the value is retrieved wrong. For instance, the user inserts 001.000 and when the application reloads the control, the value updates to 100.000.
First time I thought that it would be a Culture issue, but the user uses the same as mine (es-ES) and I have included information about culture in the code (invariant culture). This is the definition of the textbox:
this.tbxFrequency10.Culture = new System.Globalization.CultureInfo("");
this.tbxFrequency10.Location = new System.Drawing.Point(177, 254);
this.tbxFrequency10.Mask = "000.000";
this.tbxFrequency10.Name = "tbxFrequency10";
this.tbxFrequency10.PromptChar = '0';
this.tbxFrequency10.Size = new System.Drawing.Size(135, 20);
this.tbxFrequency10.TabIndex = 116;
this.tbxFrequency10.TextMaskFormat = System.Windows.Forms.MaskFormat.IncludePromptAndLiterals;
this.tbxFrequency10.Validated += new System.EventHandler(this.Control_Validated);
The main problem here is I can't reproduce the bug the user has. Just in case I changed my Windows regional configuration in order to try to reproduce the bug but with no success. Anyone has an idea about what could be the reason of this bug?
Thanks in advance. Sorry for my english.
Regards,
|
|
|
|
|
The behavior is by design[^];
MSDN states: "." -> Decimal placeholder. The actual display character used will be the decimal symbol appropriate to the format provider, as determined by the control's FormatProvider property.
Bastard Programmer from Hell 
|
|
|
|
|
Where is the code that stores and restores the value? (Or the data binding definition, if you have bound the text box?)
You should use CultureInfo.InvariantCulture not new CultureInfo(""), but that is unlikely to be the source of the problem.
|
|
|
|
|
The problem appears when the program validates the textbox content. There is where the value is updated:
if (control.DataBindings.Count > 0)
control.DataBindings[0].ReadValue();
The value is restored from a String variable which has the correct value. The main problem here is I can't reproduce the bug in any machine, it only happens with the user machine so I can't debug it properly.
Anyway, I have been reading too much about MaskedTextBox (and its possible bugs) and there is nobody with my problem. It seems the bug should come from another part of the code. I have heritage this code from the previous developer of the application and it's not a very good code (he does really tricky things just to update the textbox) so I'm going to remake this part.
I will let you know if the bug persist or the solution if I find it.
Thanks for your replies.
|
|
|
|
|
I have this method:
public List<ProjectModel> GetProjects(ProjectType ProjectType, bool ActiveOnly = true, int ParentId = 0)
{
using (SparesDataContext context = getDataContext())
{
List<ProjectModel> retVal = (from p in context.tblProjects
where p.ProjectTypeId == (int)ProjectType &&
p.ParentId == (ParentId == 0 ? p.ParentId : ParentId) &&
p.IsActive == (ActiveOnly ? true : p.IsActive)
select new ProjectModel
{
ParentId = p.ParentId,
ProjectType = (ProjectType)p.ProjectTypeId,
Caption = p.Caption,
Warehouse1 = getWarehouseModel(p.WarehouseId1 == null ? 0 : p.WarehouseId1.Value),
Warehouse2 = getWarehouseModel(p.WarehouseId1 == null ? 0 : p.WarehouseId1.Value),
IsActive = p.IsActive.Value,
Revision = p.Revision,
Comments = p.Comments
}).ToList();
return retVal;
}
}
The Warehouse Id's can be null in the table. In this code if the WarehouseId from the table
is null I convert it to 0 before calling getWarehouseModel. If it's zero I then return an empty WarehouseModel.
This doesn't feel right. Anyone know a better approach?
Thanks
Everything makes sense in someone's mind
|
|
|
|
|
Kevin Marois wrote: Anyone know a better approach?
Don't allow NULLs as WarehouseIds. Seriously, don't. What is the reasoning behind allowing them?
|
|
|
|
|
If the database allows for nulls in the column, then he may not have much choice but to handle them.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Yes, but that doesn't answer my question.
|
|
|
|
|
Because not all projects have warehouses
Everything makes sense in someone's mind
|
|
|
|
|
Then the simplest solution is to have a "Not a warehouse" entry in the warehouse table. This technique works well if you present a (drop down) list of warehouses to the user who can then select the warehouse.
However, personally, I'd prefer, rather than having a warehouse Id column in the project table, having a (many-to-many) relationship table. Some projects would have an entry (just one), others would have no entry. This is likely a better design for your project*, but I suspect your project is too far along to do it this way.
* A warehouse has several projects, a project doesn't have a warehouse.
modified 18-Jan-12 19:58pm.
|
|
|
|
|
Why is having a 'no warehouse warehouse' better than allowing nulls in the table? A null is actually what best represents the situation the data's representing, and it makes the special case code a lot more obvious (comparing to null instead of comparing to a particular row key).
And adding a relationship table when it is a (nullable) many-to-one relationship seems like overkill, too.
|
|
|
|
|
BobJanova wrote: better than allowing nulls
It's just a way to avoid the special cases, and allows for addtional functionality, but it's really just a bandaid to cover up a flaw in the schema. I (probably) wouldn't do it that way.
BobJanova wrote: A null is actually what best represents the situation the data's representing,
Yes, but the schema doesn't seem to represent the real world.
BobJanova wrote: many-to-one relationship seems like overkill
Not to me. And from what I can tell, it better represents the real world. And, after reviewing the question again I see he already has two warehouses so he really should have many-to-many.
|
|
|
|
|
PIEBALDconsult wrote: It's just a way to avoid the special cases, and allows for addtional
functionality, but it's really just a bandaid to cover up a flaw in the schema.
I (probably) wouldn't do it that way.
You are claiming that a 'zero or one' type of association automatically insures a design flaw?
PIEBALDconsult wrote: es, but the schema doesn't seem to represent the real world.
What "real world"?
In my real world a specific inventoried item can either be non-existent (out of stock) or it exists in exactly one warehouse.
How do you keep one specific item in more than one warehouse?
|
|
|
|
|
jschell wrote: automatically insures a design flaw?
No, but it seems it is in this case.
jschell wrote: What "real world"?
I don't know, the post.
jschell wrote: in exactly one warehouse.
Yes, the item is in the warehouse, the warehouse is not in the item.
|
|
|
|
|
'X is in a Y' is usually represented by a Y column on table X, so a Warehouse column on table Item is what you'd expect in this case.
|
|
|
|
|
But, in my opinion, that's a poor design; it's better for 'X has a Y'.
The warehouse is not an attribute of the item, the item doesn't require a warehouse even if it is frequently in one.
BobJanova wrote: is usually represented by
Just because others are doing it, doesn't mean it's the correct way.
And it really seems like a bad idea for the particular code that was posted.
|
|
|
|
|
PIEBALDconsult wrote: The warehouse is not an attribute of the item, the item doesn't require a warehouse even if it is frequently in one.
To be clear in discussing the database schema....
That is design view.
The implementation, not design, can take one of two paths. And using one column is better in this case because it has less impact and because there is not possibility at all that the object can live in more than one warehouse.
Using a link table provides no functional benefit, provides no future benefit and will not make it any clearer to the next implementator what the relationship is.
If there was another different model, something besides inventory item and warehouse then a link table might be a better implementation choice.
|
|
|
|
|
jschell wrote: there is not possibility at all that the object can live in more than one
warehouse
Did you miss the part where the original code says "Warehouse2"? And this particular code refers to a "ProjectModel", not some item -- I don't know what the project is but it could be building an airplane, with some parts in one warehouse and others in another warehouse, and apparently some projects aren't in a warehouse at all.
jschell wrote: a link table provides no functional benefit
It would solve the poster's null-handling problem.
jschell wrote: provides no future benefit
It allows the "ProjectModel" to have any number of warehouses.
jschell wrote: If there was another different model, something besides inventory item and
warehouse
I'm pretty sure that's what the poster has.
And now for an anecdote: Many years ago I was helping maintain a system which had a table for holding customer accounts; some fields were used to hold a credit card number, type, and expiration date (not required). All well and good. Then a new client wanted their customers to be able to have two credit cards on file. I had to add copies of those same three fields, plus another to indicate which one was last used.  Then yet another new client wanted to allow their clients to have checking account information on file so they could do electronic transfers. More stinking fields were added to the table.
The system would have been much easier to maintain had the original developers made a separate table to hold information related to this sort of thing.
You should always allow for maximum flexibility because you do not know what the future holds, and Murphy is just around the corner.
I believe this portion of this article http://en.wikipedia.org/wiki/Database_normalization[^] is appropriate:
"
Minimize redesign when extending the database structure
When a fully normalized database structure is extended to allow it to accommodate new types of data, the pre-existing aspects of the database structure can remain largely or entirely unchanged. As a result, applications interacting with the database are minimally affected.
"
|
|
|
|
|
PIEBALDconsult wrote: You should always allow for maximum flexibility because you do not
know what the future holds, and
I agree that neither I nor anyone else knows what the future holds.
Your view requires that the entire enterprise system must be over engineered based on the expectation that out of every 100 "flexible" design/implementation choices that one will be used.
That ignores the cost of implementing the other 99 in the first place and maintaining them for years.
PIEBALDconsult wrote: hen a fully normalized database structure is extended
No one in their right mind "fully" normalizes a database, so that statement is obviously false from the start (think 5th normal form.)
|
|
|
|
|
BobJanova wrote:
Why is having a 'no warehouse warehouse' better
than allowing nulls in the table? A null is actually what best represents the
situation the data's representing, and it makes the special case code a lot more
obvious (comparing to null instead of comparing to a particular row
key).
And adding a relationship table when it is a (nullable)
many-to-one relationship seems like overkill, too.
All of that seems exactly correct to me as well.
|
|
|
|
|
If there is too much downstream code already written that reference Warehouse1 and Warehouse2, then I like your approach. If you can, then downstream code should be able to handle Warehouse1 and Warehouse2 being nulls within the ProjectModel in which case you could just return null from getWarehouseModel or wrap the call with
p.WarehouseId1 == null ? null : getWarehouseModel( p.WarehouseId1.Value )
I wasn't, now I am, then I won't be anymore.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
